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PREFACE 


This manual was written for customer systems programmers, DEC Software 
Specialists, and internal maintenance programmers. Readers must be 
familiar with the DOS User's Manual, DEC-IS^ODUMA-B-D,, In addition, chap- 
ter 8 requires familiarity with the BOSS Reference Manual, DEC“15“OBUMA“-A-D. 

Technical changes reflected in this revision are indicated by a 
bar (j) in the appropriate page margin. 
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CHAPTER 1 
DOS OPERATION 



The System Manager must use DOSSAV in order to load DOS-15 for the 
first time*, The DOS System Generator manual, DEC-USGNA-A-D, describes 
DOSSAV operation in its appendix« After successful DOSSAV operation, 
the System Manager should load the Bootstrap into the highest bank of 
core memory? the bootstrap informs the DOS-15 monitor how many banks 
of core memory can be used- Before bootstrapping UC15, RK05 based 
systems^ PIREX must first be loaded and running in the PDP-11 local 
memory (refer to UC15 Software Manual DEC-15-XUCMA--A-D)« The bootstrap 
loads the Resident Monitor and the System Loader, which in turn load 
the Nonresident Monitor- In order to ensure a working system, the 
System Manager should place the DOS-15 Checkout Package tape (for 
RF15, DEC-15-0RFCA-A-PA? for RP0 2, DEC-15-0RPCA-A-PA? and for RK0 5, 
DEC-15-ORKCA-A-PA) into the Paper Tape Reader, and type BATCH PR J. 
Operating instructions for the Checkout Package, and the tape itself, 
are distributed as part of the DOS-15 system- 

Once the system has been checked out, the System Manager should use 
DOSGEN, the DOS System Generator program, to tailor the system to 
his needs- As mentioned in the System Generator manual, a complete 
tailoring of the system may also involve use of PATCH, PIP and 
UPDATE - 

Commands to the Nonresident Monitor allow temporary modification of 
the system, in order to suit the needs of a particular program- The 

Nonresident Monitor modifies the system by changing information in 

the -3COM Table- The System Loader examines the -3COM Table, along 
with three disk-resident information blocks, SYSBLK, COMBLK and SGNBLK, 
and carries out all operations necessary to fulfill the operator's 
commands - The System Loader "builds” the Resident Monitor by relocat¬ 
ing and linking those routines indicated by the -3COM table as needed 
by the next core load- The Resident Monitor then retains general 
control over the system- 
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CHAPTER 2 


THE RESIDENT MONITOR 


2.1 INTRODUCTION 

The Resident Monitor gets its name because it seems resident to the 
user a Strictly speaking, however, the only part of the system that 
is always resident is the Bootstrap. There are two parts of the 
system that are refreshed only after manual Bootstrap loads and re¬ 
starts s „SCOM and the Resident Monitor Patch Area„ Every time an 
operator or program changes certain key system parameters, the system 
will build a new Resident Monitor from blocks stored on the system 
device«, 

The Resident Monitor is the interface between the operator and the 
active devices on one hand, and the program which is running (the 
Nonresident Monitor), on the other. The Resident Monitor always 
contains the following routines and tabless 


Chapter 5 


This 

Chapter 


f . DAT 
I .UFDT 
V .3COM 

The CAL Handler, which routes all System and I/O 
Macro calls 

The Startup routine, called after using the Bootstrap 
i .MED, the Monitor’s standard error routine 
i The Expanded Error Processor, for more flexibility 
i with error messages 

j Handlers for the following error conditions: 
Nonexistent Memory 
Memory Protect 
/ Interrupt-Memory Parity 
^ Power-Fail 

Software API not set up 

The Monitor's T RAN routine (different from X/O .TRAN’s 

A clock handler 

A poller for UNIBUS device error messages (for 
UC15 systems, RK05 based or RF15/RP02 based 
1 with UC15 option only) 

The .GTBUF and GVBUF processor 

The CTRL Q processor 

The a USER processor 
I The cOVRLA processor 

TTA. 

The Resident Monitor’s Patch Area 

Task Control Blocks (for UC15 systems, RK05 based or 
RF15/RP02 based, with UC15 option) 


In addition, the user can request the system to retain certain other 
routines in a resident Monitor status; 


The CTRL X Feature, including a driver for the VT-15 
The Paper Tape or Card Reader Handler for Batch 
The Resident Batch Code 


BOSS-15 also has resident routines, which are covered in Chapter 8 







2.2 THE CAL HANDLER 


The CAL instruction transfers control to register 21, bank 0, and loads 
register 20 with the address of the next instruction after the CAL. 

All DOS I/O and system macros take the form of a CAL instruction (pos¬ 
sibly with some code in the low-order bits), and the next sequential 
register contains a dispatch code. Some macros require more informa¬ 
tion in succeeding registers. Figure 2-1, Resident Monitor CAL Handler, 
illustrates the operation of that portion of the Resident Monitor. The 
CAL Handler does only minimal error checking -- for a legal function 
code and for a legal .DAT slot. Aside from that and ensuring the 
clock is turned on, the CAL Handler is only a dis-oatcher to other 
routines. 

2.3 IOPS ERROR HANDLER AND THE EXPANDED ERROR PROCESSOR 
2.3.1 .MED 

There are two error processors in the Resident Monitor: .MED and the 
Expanded Error Processor. Figure 2-2 illustrates those routines. 

Figure 2-3 shows two subroutines used by the error routines. .MED 
(location 3, bank 0) processes IOPS errors from all device handlers 
except the disk handlers, CDB., MTF., TTA., and LPA. Calls to 
.MED should take the following form, if not IOPS 4; 

LAC INFO /ARGUMENT OF ERROR 

DAC* (.MED /ADDRESS OF CAL IS ALREADY IN .MED, 

/IF DESIRED 

LAW N /N IS ERROR CODE 0 < N<777. AC MUST BE NEGATIVE 

JMP * ( .MED+1 

IOPS 4 messages may take the following form: 

LAC (4 /AC MUST BE POSITIVE 

JMS* (.MED 

.MED+1 contains a JMP to the Monitor Error Diagnostic Routine. The 
above calls to .MED will cause the following printouts: 

IOPSN (contents of .MED) 

I0PS4 
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dress 

on 

lister 7, if 
two 



Handler 















/ SETTLE 
Wait for 
\ TTY 


f SETTLE 
Wait for 
V TTY 


Error \ N 


/ IQPS 
(Give error 


/ IQPS \ 
Give error 
\ message / 


Put recovery PC in .MED] 
^LOC-j-^ V N 

. 

f print the message ] 


/ Resident Monitor \ 

1 Initialization y- y Loop — 

NOTE_: The Nonresident Monitor HALT and 
QDUMP commands will change this loop to 
the appropriate action. BOS and Batch¬ 
ing Mode abort the $JOB. 



Await a character 
from the keyboard 


y ctrl\ 

QAREA ade- 
\ quate^ 


(Wait fDr a 
ControL Cha 


CTRL 
P, C. T, 


I Echo Command I 

-— T 

Resident Monitor 
Initialization 


, Dispatch to v 
( appropriate ] 
'V address y 


Echo Command 

Restore API, if required 
Restore PI 


Return 
via .MED 


Figure 2-2 

Expanded Error Processor 
and 

Monitor Error Diagnostic Routine 
MED 






Figure 2-3 

Resident Monitor Subroutines 


















2,3.2 The Expanded Error Processor 


The disk handlers (except the Bootstrap), CDB., MTF., TTA., and LPA. 
use the Expanded Error Processor, Each error message is "potentially" 
recoverable by typing CTRL R. That is, the Resident Monitor always 
returns control to the caller upon a CTRL R. It is up to the caller 
to respond accordingly. All handlers supplied with the system simply 
repeat the error message if the error is unrecoverable. 

The Expanded Error Processor gives the capability of printincr addi¬ 
tional information after the standard IOPS message. As with .MED, the 
AC must contain the error number (0<number<_7 7 7) in bits 9-17. Control 
must be passed, however, via JMS* (.SCOM+37, not JMP* (.MED+1• 

The following information pertains to the message: LOC+2 must contain 
the two's complement of the number of message words to be typed after 
the standard "IOPSNN nnnnnn" message. If the number is zero or posi¬ 
tive, no message will be printed. If the LINK is set, nulls will be 
printed as spaces. If the LINK is zero, nulls will be ignored. If 
the AC is positive on calling the expanded error facility, only the 
special message will be printed. The "IOPS" part will be omitted. 

The message itself must be packed in .SIXBT. 


The following are examoles of use of the Expanded Error Processor: 


Example a: 


UNREC 


LAC 

STATUS 

/STATUS REGISTER B 

DAC* 

(.MED 

/CAL ADDRESS IS NOW OVERWRITTEN 

/BY CONTENTS OF STATUS REGISTER 

SZL 


/IGNORE NULLS 

LAW 

ERRNUM 

A ERRNUM -1000 

JMS * 

( .SCOM+3 7 


JMP 

UNREC 

/THIS IS AN UNRECOVERABLE ERROR. 
/JMP .-1 WILL NOT DO -- EXPANDED 
/ERROR PROCESSOR CHANGES THE 
/CONTENTS OF .MED. 

LAW 

-6 

/6 DATA WORDS FOLLOW 

.SIXBIT 'DKA' 

/DEVICE NAME 

40 


/NULL, NULL, SPACE 

.SIXBT 

1 FIL' 

/FILE NAME (2 WORDS) 

.SIXBIT ! E 1 

40 


/NULL, NULL, SPACE 

.SIXBT 

'SRC' 

/EXTENSION 


The printout from that code will be as follows: 


IOPS777 nnnnnn DKA FILE SRC 

wnere nnnnnn is the contents of .MED, and equals the Status Register 
B, and ERRNUM is 777. 
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Example b: 


PARITY LAW 61 
STL 

JMS * (. SCOM-i-37 

JMP RETRY 
LAW -1 
.SIXBT ! DTA' 

The printout from that code will be as follows: 

IOPS61 nnnnnn DTA 

where nnnnnn is the contents of .MED, the address of the last CAL, 
deposited by the CAL Handler. 

2.4 THE SYSTEM BOOTSTRAP 

The System Bootstrap is nothing more than a disk driver. It may load 
the System Loader and Resident Monitor from Hardware Readin or manual 
restart. All other Bootstrap operations result from the use of the 
Monitor TRAN routine. The Monitor TRAN routine sets up the Bootstrap 
to read or write any block or set of contiguous blocks from the disk 
to or from any location in core. Before calling the Bootstrap, the 
Monitor TRAN does a .WAIT to all .DAT slots in the Mass Storage Busy 
Table, clears all flags, turns off the VT if it were on, and allows the 
clock to tick positive, so that it will keep time but not interrupt. 

After the Bootstrap has finished, it calls the Monitor Initialization 
Routine, which updates the clock and turns on the VT, if necessary. 


/TURNS NULLS INTO SPACES 
/THIS IS A RECOVERABLE ERROR 


The Monitor TRAN Routine requires the followincr parameter table: 

BLKNUM /FIRST BLOCK NUMBER 

FIRSTA-1 /FIRST ADDRESS OF BUFFER, MINUS ONE 

-SIZE /# OF WORDS TO BE TRANSFERRED IN 2'S COM 

START /STARTING ADDRESS AFTER DISK I/O 

/COMPLETION 

The following code illustrates the use of the Monitor TRAN: 

UNIT=10,0000 /MONITOR TRAN WILL USE UNIT ONE 1 


PARADb LOC+0 
LOC+1 
L0C+.2 
LOC+3 


.SCOM=100 


LAC (PARADD 
XOR UNIT 

STL 

JMP* (.SCOM+55 


/MONITOR TRAN REQUIRES ADDRESS OF 
/PARAMETER TABLE IN BITS 3-17 AND 
/UNIT NUMBER IN BITS 0-2 OF AC 
/NONZERO LINK GIVES TRAN OUT 
/.SCOM+55 IS USER ENTRY POINT FOR 
/MONITOR TRAN 


See also paragraph 5.7. 


DECdisk TRANs ignore unit number 


use block number. 






.OVRLA, .EXIT, and manual Q dumps all use the Monitor TRAN routine. 
Figure 2-4, .OVRLA, .EXIT and CTRL Q, illustrates their operation, 
and also the Monitor TRAN. 

For the RF DECdisk, the user can reference a specific platter just by 
identifying the block number he wants. That is, the block numbers do 
not automatically go to zero at the beginning of every platter. The 
block numbers and platter relationships are shown below: 

Table 2-1 


RF Platter—Block Number Correspondence 


Platter Number 

Block Number 

0 

0-1777 

1 

200.0-3 7 77 

2 

4000-5777 

3 

6000-7777 

4 

10000-11777 

5 

12000-13777 

6 

14000-15777 

7 

16000-17777 

(All numbers are in octal) 


2.5 SYSTEM I/O INITIALIZATION 

There are two routines that do DOS I/O initialization: the startup routine 
after Bootstrap manual loads and restarts, and the startup routine 
performed after Monitor TRAN's and after a CTRL C, p, t or S for an 
error. The startup routine after Bootstrap loads is described in 
Figure 4-1, The System Loader Interface Routine. Figure 2-5, Resident 
Monitor Initialization, describes the other routine. 

2.6 RESIDENT MONITOR TIMING FEATURES 

Figure 2-6, The Resident Monitor Clock Routine, describes the Resident 
Monitor's time functions. There are three daces in DOS which start 
or try to update the clock -- (1) the first-time initialization after 

manual Bootstrap loads and restarts, (2) the Resident Monitor Initial¬ 
ization, and (3) the CAL Handler. The following .SCOM registers con¬ 
tain timing information: 
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o 0VRLA 
CAL Entry 


Put System pr< 
gram name int< 
,SCOMt43,44 (p 
name pointed t 
by CAL+2) 


Scan Overlay 
Table (address in 
0 SCOM+ 3 I) for a 
match with the 
program name 




to TRAN Set up unit number 0 and 

s pointer to TRAN parame¬ 

ters for loading .SYSLD 
.Clear LINK for „ TRAN in 


Xwill \ 

overlay fil 


Set AC = 777777 


Update .SCOM+3; 
clear AC and the 
LINK (Unit 0, & 
.TRAN in) 


(MONITOR TRAN ROUTINE — Independent from 
device handler .TRAN 8 s) 


Store Unit number and 
other TRAN parameters 
in the Bootstrap 


Return to 
user 


CLEAR* 

(.WAIT) 


Put starting address into 
location 0, bank 0, and 
set the Bootstrap to go to 
Monitor Recovery Routine 
on exit 


* CLEAR does a .WAIT or a 
.INIT to each entry in 
the Mass Storage Busy 
Table. This precludes 
conflicts between disk 
I/O performed by the 
system disk handler, and 
disk lOT's issued by the 
Bootstrap, an independent 
program. CLEAR also turns 
off the clock and PI, and 
enables BANK mode. 


Bootstrap 


, Figure 2-4 

.OVRLA, .EXIT and CTRL Q 
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Set up clock so that it 
keeps running, but does 
not interrupt (ticks 
positive) 

Clear all flags 
Turn off PI and API 
Restore cell 4 to transfer 
to Error Diagnostic Routine 
Set up proper addressing 
(Bank or Page), according 
to oSCOM-i-4, bit 7 


N 


Do CTRL X restart 



l a Update the clock, and allow it to 
interrupt 

2. Clear TTY Busy Switch (Clear all 
flags ensures no I/O to TTY) 

3. Turn API on or off, depending on 
contents of register 6 (The Sys¬ 
tem Loader loads register 6 ac¬ 
cording to .SCOM+4, bit 0) 

4„ Turn on PI 


. - 

/ Exit tO 
( Proper 
location 




3 © 
4. 

5* 


Figure 
Resident Monitor 
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Notes The Clock Routine will use PI if API is busy? or down* 

Figure 2-6 

The Resident Monitor Clock Routine for non-UC15 Systems 
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.SCOM+5/ 
.S COM+ 51 
. SCOM+56 
. SCOM+60 

. SCOM+61 
. SCOM+73 
.SCOM+74 


Time of day, in hhmmss (six bits each) 
Elapsed time, in ticks 

Time limit, in seconds (zero, if no limit) 
Time left for .TIMER interrupt (zero, if 
.TIMER not in effect) 

Address of .TIMER user interrupt routine 
Number of ticks left in the next second 
Line frequency, in ticks per second 



2.6.1 Clock Operation 

The Nonresident Monitor's TIME command changes or .senses .SCOM+50. 
.SCOM+51 is not used by any system program. The clock handler simply 
increments it upon each clock tick. User programs may deposit a known 
quantity into .SCOM+51, in order to time events. The Non-resident 
Monitor deposits the argument for a TIMEST command into .SCOM+56. If 
.SCOM+56 is nonzero, the Resident Monitor will issue an ISZ .SCOM+56 
command each second, until it reaches zero. At such a time, the Resi¬ 
dent Monitor will perform a .EXIT. MICLOG, LOGIN, and LOGOUT clear 
.SCOM+56. 

2.6.2 .TIMER 

.TIMER allows users to schedule routines for a specified time from 
"now". These routines may return to the interrupted code, if the 
programmer desires. .TIMER users should take care that the time- 
dependent code follows certain rules; 


a. When a programmer does not wish to reset the .TIMER mechan¬ 
ism, but wishes to return to the interrupted program, his 
code should look like this; 


C 0 

DAC SAVEAC 


LAC C 

RAL 

LAC SAVEAC 

XIT JMP * C 


Si 

/C+l REACHED VIA JMS 

/MUST NOT USE NON-REENTRANT CODE 

/POSSIBLY USED BY THE INTERRUPTED f§ 

/PROGRAM. (INCLUDES THE CAL IN¬ 
STRUCTION) 

/RESTORE THE LINK 

/RESTORE THE AC 
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When the programmer does wish to reset the .TIMER mechanism, 
and return to the interrupted code, his routine should look 
like this? 


.SCOM=1^0 

CLON=7jW44 

CLOF=700P04 

INTRVL=-lJ$pf /THIS ROUTINE WILL RUN EVERY 100 + 

/TICKS y 

C 0 

DAC SAVEAC 


LAC 

ADDRES 

/RETURN TO THE NEXT ROUTINE 

DAC* 

(.SCOM+61 


CLOF 


/TURN THE CLOCK OFF TO ENSURE NO 

LAC 

INTRVL 

/REENTRANCE BEFORE .TIMER RESET AND 
/RETURN 

/DESIRED INTERVAL IN TWO'S COMPLEMENT 

DAC* 

(.SCOM+60 


LAC 

C 

/RESTORE THE LINK 

RAL 

LAC 

SAVEAC 

/RESTORE THE AC 

CLON 


/TURN THE CLOCK BACK ON (AFTER NEXT 

JMP * 

C 

/INSTRUCTION) 


When a programmer does not wish to return to the interrupted 
program, he need not save the AC, and he may use the CAL in¬ 
struction, He should beware of using I/O buffers that may 
still be modified by a handler's interrupt section. In many 
cases, a .INIT to an active .DAT slot will terminate I/O. 
Teleprinter I/O should be terminated by the following: 


XCT* (.SCOM+35 


The user should program a delay of at least 110 milliseconds 

after such an instruction before he attempts teleprinter I/O. 

Note: The interrupt routine will run at the level of the in¬ 

terrupted code, with the same addressing mode and memory pro¬ 
tect status. Thus, no debreak and restore is required. 




2.7 THE RESIDENT MONITOR PATCH AREA 


There are two types of patch areas 


1. That allocated by using PATCH 

2. That allocated when answering the Patch Area 
question in system generation 

Patch area one is the place for permanent changes to the Resident 
Monitor. It is always refreshed when the System Loader comes into 
core. Patch area two is only refreshed on manual Bootstrap loads 
and restarts. The second area would be appropriate for communication 
between successive programs loaded by the System Loader. This area 
should be used because the System Loader refreshes all of core, ex¬ 
cept the Bootstrap, .SCOM, the CTRL X buffer, and the patch area two. 

The combined size is limited by the current assembly at 3000 o for 

O 

RP02 and RF15 systems, and, for RK05 system. Both areas can be 
initialized, using PATCH. The important dividing line between area 
one and area two is register 101 (.SCOM+1) of RESMON. The way to 
allocate more space in part one is to increase the value of register 
101. The way to change the area in part two is to use DOSGEN• The 
second part will start at the address in register 101. The upper 
bound of the second area will be the sum of the contents of register 
101, and the number specified to DOSGEN. 

2.8 CONTROL CHARACTERS 

CTRL C, P, R, S, and T are all special characters that interrupt the 
current program and transfer control. The Resident Monitor ignores 
CTRL R except after IOPS 4 and any call to the Expanded Error 
Processor. CTRL S always transfers control to the address in .SCOM+6. 
In the case of core-image system programs and EXECUTE, a CTRL S will 
transfer to register zero, and result in an IOPS 3. The Linking 
Loader places the starting address of the first load module into 
.SCOM+6. 


A .INIT macro to the teleprinter handler will change the address of 
either CTRL C, P or T. The Resident Monitor is always initialized to 
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perform a .EXIT after CTRL C, and ignore CTRL P and T• DDT uses 
CTRL T, and CTRL P is ordinarily used by programs for restarts. 

MACRO-15 expands .INIT to change the CTRL P address. If the programmer 
expands .INIT without the aid of the assembler, a 10 in bits zero and 
one of LOC+2 will change the address of CTRL T. A 01 in those bits 
will change the address of CTRL C. It should be obvious that special 
care should be taken with CTRL C. In addition, modifications to the 
CTRL T address should not be made when debugging with DDT. There are 
cases, however, when such modifications are desirable. In particular, 
all zeroes in LOC+2 (2-17) will cause the teleprinter handler to 
ignore CTRL C, P, or T. This address might be used when sensitive 
code is being executed, as in DOSGEN. The following .INIT expansion 
will cause the Resident Monitor to ignore CTRL C: 


CAL-2&777 

1 

200000 

2.9 TASK CONTROL BLOCKS (only for UC15 system - RK05 based or 
RF15/RP02 based with UC15 option) 


In the UNICHANNEL-15 system communication between the PDP-15 and the 
PDP-11 is through blocks of information called Task Control Blocks. 
These blocks are resident in the common/shared memory space (memory 
that can be addressed both by the PDP-15 and the PDP-11)„ The TCB 
contains all the information necessary (like the addressed task 
code, the method of indicating the completion of a request, memory 
address, word count, operation etc.) for the PIREX system to process 
that request (refer to UC15 Software Manual, DEC-15-XUCMA-A-D for more 
details). 


Handlers for the devices on the UNIBUS communicate with the driver 
tasks running under PIREX through TCB's. In order to permit these 
handlers to be loaded anywhere in core (not restricting them to the 
common/shared memory) , these TCB's are part of the Resident Monitor. 
.SCOM+100 points to a table in the Resident Monitor which contains 
the start address of the various TCB's present in the system as 


indicated below: 


• SCOM+100 


TCBTAB 


TCBTAB 


RKTCB 

LPTCBF 

CDTDBF 

PLTCBF 

SITCB 

S2TCBF 

S3TCBF 


NAME SIZE (octal words) 


RKTCB 

21 

LPTCBF 

117 

CDTCBF 

65 

PLTCBF 

117 

SITCB 

24 

S2TCBF 

120 

S3TCBF 

170 
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The following are available for use when the handlers are in operation. 
RKTCB - TCB for the RK05 disk cartridge handler 

LPTCBF - TCB and buffer space for the LP11/LS11 line printer handler 

CDTCBF — TCB and buffer space for the CRll card reader handler 

PLTCBF - TCB and buffer space for the XY11 plotter handler 

The following are available for new devices or for other purposes 
as desired by the user 

S1TCB - Spare TCB space 

S2TCBF, S3TCBF - Spare TCB and buffer space 

The TCB and buffer space starts below this table and .SCOM+1 points 
to the end of the TCB and buffer space. Users can add entries to 
this table for TCB 8 s or TCB and buffers by suitable updating „SCOM+1 
and the table,. 
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CHAPTER 3 


THE NONRESIDENT MONITOR 








3.1 INTRODUCTION 

The System Loader brings the Nonresident Monitor into core after a 
hardware readin, a manual restart, a CTRL C, or a .EXIT. The RCOM 
Table, SGNBLK, SYSBLK and COMBLK are always coresident with the Non¬ 
resident Monitor, This gives the Nonresident Monitor access to all 
important system parameters. 

The Nonresident Monitor announces its presence by typing DOS-15 Vnn 
on the teleprinter. It remains in core until the operator requests 
another system program, or until the operator’s command implies a 
refreshed configuration of the Resident Monitor is necessary. 

The Nonresident Monitor's actions are limited to (1) decoding commands, 
(2) manipulating or examining bits and registers in „SCOM, .DAT, .UFDT, 
SYSBLK, COMBLK, and SGNBLK, and (3) callincr the System Loader, when 
necessary. The Nonresident Monitor has only one entry, which starts 
an initialization section. Figure 3-1, Nonresident Monitor Initial¬ 
ization, describes that logic. Every time the System Loader brings 
in the Nonresident Monitor, it passes control to the initialization 
section. After initialization, and after all commands that do not 
require the System Loader, the Nonresident Monitor types a $ and 
awaits an input line, terminated by a Carriage RETURN or an ALT MODE. 

It then examines the first six characters (or those u.p to the first 

blank) and tries to find an entry in the Nonresident Monitor's Command 
Table. If a match is found, control passes to the appropriate routine, 
and thence to the next command or the System Loader. If the typed 
command does not correspond to an entry in the command table, the 
Nonresident Monitor temporarily assumes the operator wishes a new 
core-image system program and checks COMBLK for a corresponding entry. 
If there is no corresponding entry in COMBLK, the Nonresident Monitor 
will type an error message and await the next command. If COMBLK 
contains a matching entry, the Nonresident Monitor composes a .OVRLA 
and passes control to the System Loader via that .OVRLA. 
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(next page) 
Figure 3-1 


Nonresident Monitor Initialization 
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Figure 3-1 (Cont,,) 
Nonresident Monitor Initialization 














3.2 COMMANDS TO THE NONRESIDENT MONITOR 


This paragraph discusses legal commands listed in the Nonresident 
Monitor's Command Table. Table 3-1, Effects and Exits for Nonresident 
Monitor Commands f describes all commands that do not request a new 
program. 

There are five entries in the Command Table that load relocatable 
system programs. They are DDT, EXECUTE, GLOAD and LOAD. The Non¬ 
resident Monitor treats these commands separately, because SYSBLK 
does not list them. All information necessary for loading these pro¬ 
grams resides in the Nonresident Monitor itself. 

3.3 CONSIDERATIONS FOR ADDITIONS TO THE NONRESIDENT MONITOR 

Programmers should not attempt to add commands to the Nonresident 
Monitor unless they have access to a copy of the source code. The 
source code may be purchased from Digital Equipment Corporation, 

146 Main Street, Maynard, Massachusetts, under one of the order num¬ 
bers listed in the footnote. They should then use the EDITOR program 
to put in the indicated changes, and reassemble. 


New additions to the Nonresident Monitor require the following actions 

1. Update the Nonresident Monitor's Command Table. 

The Command Table is in two parts: 

a) The .SIXBT names of the commands 

b) The corresponding transfer vector 

2. Write the code for the command. 

3. Consider the kind of exit the command will take: 

a) Commands that end with a request for a new 
command should end with JMP KLCOM 

b) Commands that re-configure the Nonresident 
Monitor should end with JMP NRMEX1. 


DECtape, DEC-15-0DSRA-A-UA1 

Magtape (7 track), DEC-15-ODS1A-A-MA7 

Magtape (9 track), DEC-15-ODS1A-A-MA9 
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Table 3-1 


Effects and Exits 
for Nonresident Monitor Commands 1 


COMMAND 


MODIFIER 


ACTION TAKEN 


EXIT 


API 


ON 

OFF 


Set bit 0 of . SCOM4-4. 
Clear bit 0 of .SCOM+4 


ASSIGN 


handler 


BANK 


(and/or) 

UIC 


Check whether handler is available 
If yes, load .DAT slot with proper 
handler code, (The proper loader 
will load the handler, and insert 
its starting address into the .DAT 
slot. 


Load proper slot via a .USER 


ON 

OFF 


Set bit 11 of .SCOM+4. 
Clear bit 11 of .SCOM+4. 


EXIT 

.EXIT 


Next 

Command 


Next 

Command 


Next 

Command 


BATCH 


PR 


CD 


Set bit 0 and clear bit 2 in loca¬ 
tion fill of the Bootstrap’s bank. 

If bit 2 of .SCOM+33 is set (i.e., 
if VT is ON) and bit 17 of .SCOM+33 
is set (i.e., CTRL X is set for VT), 
set bit 1 of .SCOM+33 in order to 
tell the Resident Monitor Initializa¬ 
tion to start up CTRL X. 

Set bits 0 and 2 of location 1777 of 
the Bootstrap's bank, and set bit 1 
of .SCOM+33 as with BATCH PR. 


BUFFS 


number 


Put number indicated into .SCOM+26, 
and set Nonresident Monitor Initial¬ 
ization to leave .SCOM+26 alone. 


CHANNEL 


Clear bit 13 of .SCOM+4 
Set bit 13 of .SCOM+4 


DATE 


date 
no date 


Enter date into 
Print date from 


SCOM+47. 
SCOM+47. 


.EXIT 


EXIT 


Next 

Command 


Next 

Command 


Next 

Command 


1 This 


table assumes 


error-free input 
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Table 3-1 (cont.) 


Effects and Exits 
for Nonresident Monitor Commands 


COMMAND 

MODIFIER 

ACTION TAKEN 

EXIT 

GET 

GETP 

GETS 

GETT 


See Section 3 s 4 a 


HALF 

ON 

OFF 

Set bit 0 of .SCOM+33. 

Clear bits 0 and 1 of .SCOM+33. 

.EXIT 

.EXIT 

HALT 


If not in BOSS-15 mode, out a HLT 
instruction (instead of a JMP) into 
the exit from non-IOPS 4 errors to 
.MED. If in BOSS mode, do nothina. 

Next 

Command 

INSTRUCT 

none 

ERRORS 

Print INSALL SRC A By loading 

Print INSERR SRC J INSTRC BIN 

= EXIT 

Command 

KEEP 

ON 

OFF 

Set bit 16 of .SCOM+42. 

Clear bit 16 of .SCOM+42. Initial¬ 
ize to SGEN default values all en¬ 
tries in .DAT and .UFDT, except 
change SCR default values to current 
UIC. 

Next 

Command 

LOG 


Output five spaces after Carriacre 
RETURNS. After ALT MODE, go to' 
next command. 

Next Com¬ 
mand (after 
ALT MODE) 

LOGIN 

uic 

Make specified UIC current (.SCOM+41) . 
*Then set up .UFTD entries; set .DAT 
entries and system parameters (.SCOM+4, 
20, 26 , and 33) to SYSGEN default values; 
clear .SCOM+42 and 56. 

.EXIT 

LOGOUT 


Set current UIC to SCR. Then same as 
LOGIN (above) from *. 

.EXIT 

LOGW 


For BOSS-15, print message. In all 
cases, after a Carriage RETURN, out¬ 
put five spaces. After ALT MODE, 
type four bells IP, and await CTRL P. 
After CTRL P, go to next command. 

Next Com¬ 
mand (after 
ALT MODE) 

























REQUEST 


none 

USER 

prog 


ACTION TAKEN 


Set bit 3 of . SCOM+42 . 
Clear bit 3 of .SCOM+42 




EXIT 

EXIT 



Clear bit II of .SCOM+4. 
Set bit 11 of .SCOM+4. 


If n is between 0 and 7, inclusive 
enter it into .SCOM+54. 


See Section 3=4. 


Enter MANSAV, the address of the 
manual CTRL Q, into the exit from 
non-IOPS 4 errors to .MED. 



Next 

Command 



Print the current assignments for 
.DAT and .UFDT. 

Print the current assignments for 
all positive .DAT and .UFDT slots. 
Print required .DAT and .UFDT slots, 
and the assignments and use for each 

Next 

Command 

Print the information for the cur¬ 
rent system. 

Next 

Command 

Enter time into .SCOM+50. 

Print time from .SCOM+50. 

Next 

Command 

Set bit 2 of .SCOM+33. 

Clear bits 1, 2, and 17 of .SCOM+33. 
Execute STOP. 

. EXIT 

Enter 4,0.0j3'0'j2f into .SCOM+20. 

Deposit zero into .SCOM+2^. 

Next 

Command 

Clear bit 2 of .SCOM+4. 

Set bit 2 of .SCOM+4. 

.EXIT 

Set bit 2 of o SCOM+20 and clear 
bit 2 in «SCOM+4 » 

Clear bit 2 of .SCOM+20 and set 
bit 2 in .SCOM+4. 

„ EXIT 







































4 . 


After assembly, the programmer must call PATCH, in 
order to make his relocatable binary program absolute. 
Commands to PATCH should be as follows: 

>D0S15 J 

>READR 16077 DOSNRM BINj 

16077 indicates the highest location the new monitor 
can occupy. (SYSBLK begins at 16100.) DOSNRM BIN 
happens to be the file name used by program develop¬ 
ment. The programmer may, of course, substitute his 
own file name. More information may be found in the 
PATCH manual — DEC-15-UPATA-A-D. 


3.4 QFILE 


QFILE is a system program that allows users to (1) store core images 
in named files, and (2) retrieve such core images for examination via 
DUMP (or possibly for a slow, core-swapping capability). QFILE imple¬ 
ments the following Resident Monitor system macros and Nonresident 
Monitor commands: 


.GET, GET, GETP, GETS, GETT, .PUT and PUT 


Users can not obtain QFILE by typing its name to the Nonresident 
Monitor. The Resident Monitor will load QFILE as part of its response 
to the commands and macros listed above. 


PUT creates a file that contains the data in the CTRL QAREA; .PUT 
creates a file from the current core image. GET, GETP, GETS, GETT 
and .GET all overlay core with the contents of the QAREA or file. (The 
different commands specify different startup locations.) In addition 
to the above capabilities, the Resident Monitor provides the capability 
of overlaying core with the contents of the CTRL Q area. The follow¬ 


ing instructions show how to use 

UNITNO=400000 
.SCOM=100 

LAC START 

XOR UNITNO 

JMP * (.S COM4-6 4 


that routine: 


/UNIT FOUR 


/STARTING ADDRESS AFTER THE CTRL Q 
/GET 

/UNIT NUMBER IN HIGH-ORDER THREE BITS 
/ADDRESS OF CTRL Q GET ROUTINE 


8 




Figure 3-2, QFILE, and Implementation of GET and PUT Logic, shows 
the information flow associated with QFILE. QFILE uses the follow¬ 
ing registers*. 


. SCOM+7,10 & 11 .SIXBT Filename and Extension 


.SCOM+65 


.SCOM+66-71 
.DAT-14 


Command parameters, packed as follows 


Bits 0-2 
Bit 8 
Bit 9 
Bits 15-17 


Device unit number 
NRM PUT, when set 
PUT logic, when set 
Function Code 


CTRL o Area parameters 

File must be on the device assigned 
to this .DAT slot. 


NOTE 

All GET and .GET operations change all 
of core, except registers 0 through 4 
of bank zero. 


> 
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Note; This chart assumes error free input. 


Figure 3-2 

QFILE, and Implementation cf GET and PUT Logic 
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CHAPTER 4 


THE SYSTEM LOADER AND THE LINKING LOADER 


The System Loader is the third major part of the DOS-15 Monitor. The 
other two are the Resident and Nonresident parts. The Resident and 
Nonresident Monitors communicate with the System Loader by manipulat- 
ing certain .3COM registers. When commands to either part imply a 
new configuration is needed, that part sets up the appropriate . SCOM 
registers, and passes control to the System Bootstrap via the Monitor 
TRAN routine. The Bootstrap then loads the System Loader into high 
core, and gives it control. 

The System Loader examines the .SCOM registers, and loads a fresh copy 
of the Resident Monitor, including any features that the user wishes 
to be resident, such as the CTRL X feature. It will also load the 
desired system program and all handlers required by the new configura¬ 
tion. In addition, it will allocate all required buffers. The Non¬ 
resident Monitor is treated like any other core-image system program. 

The System Loader never loads user programs. It only loads core-image 
system programs, the INSTRUCT command processing program, the Linking | 
Loader and Execute,, The latter two load user programs e 

The System Loader uses two device handlers to interface with the disk; 
the System Bootstrap, and the System Loader Disk Handler (DKL®/DPL®/ 
RKL„)„ xxL. arrives in core along with SYSBLK, COMBLK and SGNBLK, 

as well as the loader itself. The Bootstrap loads core—image programs 

only,. The xxL„ takes care of relocatable programs and any handlers j 
loaded by the System Loader, Those include all handlers for core¬ 
image system programs, the Linking Loader 5 s own handlers, and any 
needed by the Execute file. The Linking Loader loads some handlers 
needed by user programs it links. 

There are two parts to the System Loader; the System Loader Interface, 
and the System Loader Proper ( s SYSLD), Figure 4-1 describes the System 
Loader Interface, Figure 4-2 describes the System Loader Proper, and 
Figure 4-3 describes the Linking Loader. 



Bootstrap 

Loads 


Turn on the clock 
Initialize 
oSCOM-4-0 First : 


, SCOM+33 


oSCOM-4-0 First free reg» 
ister below the 
Bootstrap 

„SC0M-!-4 SGEN default 
o SCOM+20 Bit zero set, if 
extra 4K? rest 
zero 

.SCOM+33 VT & HALF, as 
per SGEN 

s SCOM+74 Line frequency 
-Move to highest bank 

( Normal 
Initializ" 

____ ation 

Zero .SCOM+36, to indicate no’entries in the Mass Storage 
Busy Table 

Move Resident Monitor into lower core 
Set up: Jump to Skip Chain 

CAL* error 
Legal CAL jump 

Turn API on or off, depending on bit 0 of 9 SC0M+4 (set=on) 
Bank bit initialize Resident Monitor to talk to the 
Bootstrap, and load »SYSLD into the proper bank upon a 
subsequent „EXIT or .OVRLA* 

Initialize the Bootstrap with the proper IOPS 4 address for 
disk not ready 

Calculate the Skip Chain from SGNBLK 

Set all API channel registers to point to IOPS 3 (with the 
exception of the clock interrupt) and all software levels 
to point to IOPS 30 

Put transfer vector to .DAT slots into .SCOM+23 
Put number of positive .DAT slots into .SCOM+24 
Put pointer to «,UFDT-f-0 into „SCOM-i-25 


, last program 
Nonresident 



oTRAN image of .DAT 
and 0 UFDT out to 
block 37 of the sys 
tern device, unit 0 







Put number of system device's "A" handler (DKA* or DPA„or RKA 0 ) 
into .SCOM+57 

Set up tabbing for current teleprinter 

Set *SCOM-t-20 to initial state (as in first time initialization) 
Set up for CTRL Q ~ ignore Q-dumps if RF system and QAREA too 
small,, or nonexistent 

Set up for IOPS errors upon the following interrupts: 
Nonexistent Memory (IOPS 31) 

Memory Protect Violation (IOPS32) 

Memory Parity Error (IOPS33) 

Power Fail Not Set Up (IOPS34) 


^ Bit 0x 
of the 
Bootstrap 
\=1 / 


Non-BOSS Batch 


Set up for the i 
proper input 
device (CD or PR) | 


X Loading x* 
Nonresident 
>x Monitor / 


a $JOB card 
vbeen seen/ 


Set switch to ig¬ 
nore input until $JOB 


Next Page 
Figure 4-1 (Cont.) 
System Loader Initialization 
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6 S Set up all batch device a DAT slots to refer to the hand 
ler currently in core*, That is,, only one batch input 
device is allowed at any one time 
7* Clear $JOB read switch (bit 1 of Bootstrap 17777) 

8„ Perform .INXT to a DAT»2 


In n. 

BOSS Mode 

(Bit 0 of »SCOM+52=l^ 


/ /Lo adi ng\^ 
Nonresident 
\ BOSS / 


Clear bits 14, 15 
and 17 of „SCOMt42 


1. Relocate Resident BOSS 
and link it to the DOS 
Resident Monitor 

2. Patch DOS Resident Mon¬ 
itor to accomodate BOSS 

3* Set bits 14, 15 and 17 
of oSCOM+42, to tell 
oSYSLD to set up „DAT-7 
and 4-6 


Relocate and 
link CTRL X 
code, and give 
proper buffer 



Has 

"CTRL X been' 
typed/'" 


Set up linkages between 
CTRL X code and the 
Resident Monitor 
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Figure 4-1 (Cont.) 
System Loader Initialization 


4-4 


















From Preceding Page 


Loading 
a relocatable 
\ program X 


N / loading Y 

\ EXECUTE / 


1 0 Allocate the number of buffers 
indicated by „SCOM+26 
2 0 Set up File Buffers Transfer 

Vector Table pointer, in „SCOM+30 


XWill \ 
EXECUTE 
use system 
\ deviceX”* 


Loading 
,INSTRC y 


Store one of the following 
codes into .SCOM+6: 


Set .SCOM+5 
to 14 


LOAD 

GLOAD 

DDT 

DDTNS 

Zero .SCOM+5 


Tell 0 SYSLD by setting 
.SCOM+ll to XCS (avoids 
two handlers in core for 
same device) 


100000 

300000 

400000 

500000 


f 

A 


B 

V 

J 


Allocate number of 
buffers indicated 
by .SCOM+26 
Set up File Buffers 
Transfer Vector 
Table in .SCOM+30 
Set * SCOM+6 = 0 
Put 13 into „SCOM+5 


(Loading a Core-Image Program) 

Find entry in SYSBLK and COMBLK 

Build Overlay Table from information in COMBLK, and set .SCOM+31 to 
first word in the table 

Store the number of overlays in the overlay processor of the Resident 
Monitor 
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Figure 4-1 (ContJ 
System Loader Initialization 
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Figure 4-1 (Cont.) 
Lystem Loader Initialization 
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The System Loader 
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Loader , and place starting address into 
.SCOM+5 




B0SCK1 


Exit to ad¬ 
dress in 
v .SCOM+5 


Allocate all necessary buffers 
If the system has an extra 4K? 
put the first free address beneath 
the handlers into .SCOM+20 
Update first free location in core 
shown in .SCOM+2 — .OVRLA updates 
the first free address beneath the 
Bootstrap? .SCOM+3_ 


BOSCKl 


/ Exit via | 

V .OVRLA J 

Subroutine BOSCKl does the following? if loading a program under BOSS-15 
(1) .USER to oUFDT-7 ? (2) „SEEK to .DAT-7 for PRCFIL PRC. 

Figure 4-2 (Cont.) 

The System Loader 
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Figure 4-3 
The Linking Loader 
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The Linking Loader 
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The Linking Loader 








4.1 MANUAL BOOTSTRAP LOADS AND RESTARTS 


Manual Bootstrap loads and restarts bring blocks 0-36 of the system 
device into the lowest bank. These blocks contain the Resident Moni¬ 
tor, the System Loader Interface Routine, and SYSBLK, COMBLK and SGNBLK. 
Figure 4-4 illustrates the core load after manual Bootstrap loads and 
restarts. The Interface sets up .SCOM+0, 4, 20, 27, 33, 54 and 74 
from SGNBLK values determined at system generation time, and then 
transfers the whole core image of the Interface to the Bootstrap’s 
bank. (DOS requires 16K, because this bank must be different from 
bank 0.) At all other times, the Bootstrap loads the System Loader 
into its own bank. This preserves the image of .3COM, part two of 
the Resident Monitor patch area, and the CTRL X buffer. For UC15 
systems (RK05 based and RF15/RP02 based with UC15 option) this has 
no effect on the core layout in the PDP-11 local memory. PIREX is 
reinitialized meaning all permanent tasks are put in a ’WAIT’ state 
while temporary tasks are put in a ’EXIT’ state and all pending 
PDP-15 requests are flushed (refer to UC15 Software Manual, 
DEC-15-XUCMA—A—D for more information). 

4.2 LOADING SYSTEM PROGRAMS 

The System Loader Interface Routine gets control in the highest bank, 
either by a transfer from the lowest bank, or by load from the Boot¬ 
strap. After setting up for the System Loader Proper (.SYSLD), 
according to the program to be loaded and the settings of certain 
SCOM registers, the Interface Routine brings it in as a complete 
overlay. Figure 4-5 illustrates the core configuration of the 
Interface when it is in the highest bank. (The addresses provided 
are for a 16K system.) The System Loader loads handlers from the 
lowest part of free core up, with the exception that the extra 4K is 
filled first, if it exists. Core image system programs are usually 
loaded just beneath the Bootstrap (always in the highest bank). Such 
core images must be wholely within the top bank of core, and above 
register 17 of that bank. Figure 4-6 illustrates the core maps for 
system programs. 

Whenever the Linking Loader is loaded (LOAD, GLOAD, DDT, and DDTNS), 
the System Loader loads all handlers for .DAT slots -1, -4, and -5, 
and then loads the Linking Loader itself, (DDT is loaded by the 
Linking loader.) Wherever INSTRC ($INSTRUCT command processing 
program) is loaded, the handler assigned to .DAT slot-12 is also 
loaded. Figure 4-7 illustrates the core maps for the Linking Loader 
and INSTRC. 
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Figure 4-8 
Execute 
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For EXECUTE, the System Loader loads EXECUTE 5 s handler, and reads the 
EXECUTE file, in order to determine the active .DAT slots. The 
System Loader then loads all the handlers required, and sets up the 
.DAT slots. Figure 4-8 illustrates core maps for EXECUTE. 

BOSS-15 Mode operation requires the system "A" handler be assigned to 
.DAT-7. This requires a sleight of hand on the part of the System 
Loader, which needs the "L" handler on .DAT-7. It therefore loads 
the "A" handler as if it were assigned to .DAT+0, and transfers the 
set up .DAT slot 0 contents to .DAT-7 before transferring control to 
the program being loaded. .DAT+0 is then restored to its original 
status. 

4 o 3 TABLES AND INFORMATION BLOCKS USED AND BUILT BY LOADERS 

The System Loader uses SYSBLK, COMBLK, SGNBLK, block 37 of the system 
device, .SCOM, the RCOM Table, the IOC Table, the Device Table, the 
Mass Storage Busy Table, the File Buffers Transfer Vector Table, the 
Overlay Table, .DAT, .UFDT and three bits in the Bootstrap. Tables 
4-1, 4-2, and 4-3 describe how the Loaders use these blocks and tables. 

4.4 .DAT SLOT MANIPULATION BY THE SYSTEM LOADER 

The System Loader maintains the .DAT slot device handler assignments 
as they were the last time the Nonresident Monitor was in core. The 
Loader saves the .DAT and .UFDT on the system device whenever the 
Nonresident Monitor was the last program in core. Thereafter, the 
Loader refreshes .DAT and .UFDT from the image on the disk. If KEEP 
is off, the Nonresident Monitor's initialization routine restores the 
.DAT and .UFDT to default values. 

When loading core—image system programs, the System Loader determines 

the active .DAT slots by examining COMBLK. When loading EXECUT, the 
System Loader sets up .DAT-4, and any active slots indicated by the 
Execute file itself. When loading the Linking Loader, the System 
Loader sets up .DAT-1, -4, and -5 and also .DAT-12, if loading INSTRC.I 
The Linking Loader will set up other active .DAT slots according to 
the .IODEV commands in the assembly of the program units being loaded. 

Both the System Loader and the Linking Loader set up .DAT slots in 
this manner: (In the following procedure, "loader" refers to either 

one.) 


4-15 



Table 4-1 


Tables and Blocks 
Used by the Loaders 


NAME 

USE 

LOCATION 

SYSBLK 

The System Loader obtains Monitor TRAN 
parameters from SYSBLK when it builds 

16500 of 
.SYSLD’s bank 

COMBLK 

Indicates number of buffers required, 
the active .DAT slots, and the names 

17100 down, in 
.SYSLD ! s bank 

SGNBLK 

Default settings for .SCOM registers, 
number of words per buffer, size of 
Resident Monitor's patch area (part 
two), Skip Chain, .DAT and .UFDT de¬ 
fault contents, and handler informa¬ 
tion . 

16100 of 
. SYSLD’s bank 

Block 37 
of the Sys¬ 
tem Device 

Image of .DAT and .UFDT, when last pro¬ 
gram was loaded (excluding the Nonresi¬ 
dent Monitor). 


„SCOM Table 

See Table 4-II. 

100 of 1st bank 

RCOM Table 

Moved for use by the Nonresident Monitor. 

17500 of the 
highest bank 

IOC Table 

Built by Interface Routine for .SYSLD 
itself. 

Just beneath 
the System 
Loader 

Device 

Table 

Built by Interface Routine if loading 

PIP, or if PIP is among the overlays 
listed in COMBLK 

Just above 
.SCOM+1 

Mass Storage 
Busy Table 

Built by the System Loader itself. 

Pointed to by 
.SCOM+62 

File Buffers 
Transfer Vec¬ 
tor Table 

Allocated by the Interface Routine, and 
initialized by it for non-core Image 
programs. System Loader proper initial¬ 
izes for core-image programs. 

Pointed to by 
.SCOM+30 

Overlay 

Table 

Built by the Interface Routine 

Pointed to by 
.SCOM+31 

.DAT 
and 
. UFDT 

Image stored and restored from block 37 
of the System Device. The System Loader 
loads all handlers for core-image pro¬ 
grams and EXECUTE Files, and sets up 
the appropriate .DAT slots. The System 
Loader also loads handlers assigned to 
.DAT-1, -4, and -5 when loading the 
Linking Loader, and .DAT-7 and +6 for 
BOSS-15. 

Pointed to by 
.SCOM+2 3 and 
.SCOM+2 5 

BOOTSTRAP 

Bits 0, 1, and 2 of location 17777 in 
the Bootstrap's bank used for Batch (non- 
BOSS) information. 

J_ 
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Table 4-2 


oSCOM Registers Used by the System Loader 


.SCOM+ 

Description of Use by the System Loader 

0 

Set in first-time initialization routine. Used to locate 
the System Loader Command Area, which is just below the 
Bootstrap. 

1 

System Loader Interface routine updates this indication 
of the first free register above the Resident Monitor 
each time it moves a piece down to low core. 

2 

The Interface and .SYSLD itself continually update this 
indication of the first free location as they move code 
and build tables. 

3 

Updated as with .SCOM+2. Last free location in core. 

4 

First Time Initialization routine sets this register ac¬ 
cording to a SGNBLK parameter, [ 

Refer to Table 4-III. [ 

5 

Interface Routine stores code of program to be loaded 
into .SCOM+5. .SYSLD uses .SCOM+5 for starting address 

when loading EXECUT or LOAD. The .OVRLA routine loads 
.SCOM+5 with starting address of the Monitor Recovery 
Routine. The Bootstrap transfers to the address in 
.SCOM+5 after all its operations. 

6 

Interface Routine stores codes for DDT, DDTNS, LOAD and 

GLOAD into .SCOM+6. For other programs, the Interface 
Routine zeroes .SCOM+6. 

7 

.SYSLD saves contents of .DAT-1 in .SCOM+7, when loading 
the Linking Loader. When loading EXECUT, .SCOM+7 con¬ 
tains the first three characters of the Execute file’s 
name. Contains .DAT-12 when loading Nonresident Monitor. 

10 

.SYSLD saves contents of .DAT-4 in SCOM+1^, when loading 
the Linking Loader. When loading EXECUT, . SC0M+1J? con¬ 
tains the second three characters of the Execute file’s 
name. 

11 

.SYSLD saves contents of .DAT-5 in .SCOM+11, when loading 
the Linking Loader. When loading EXECUT, .SCOM+11 con¬ 
tains the extension of the Execute file's name. (The 

Interface routine sets .SCOM+11 to XCS, telling .SYSLD 
that EXECUT will be using the system device. .SYSLD 

then restores .SCOM+11 to XCT.) 

12- 

The Interface routine initializes these transfer vectors 

15 

for API software levels to point to SERR, an error routine 
that will produce an IOPS3j2f. 

16 , 

17 

Unaffected. 
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Table 4-2 (Cont.) 


SCOM+ 


20 



,SCOM Registers Used by the System Loader 


Description of Use by the System Loader 


Bit zero set in first time initialization, if system con¬ 
tains an extra 4K. If the system does contain an extra 
4K, the System Loader will load handlers in that page — 
from the bottom up — when loading a core-image program. 
Whenever there is an extra 4K, the System Loader will 
update bits 3-17 with the address of the first free cell 
in the extra 4K. If bit 2 is set, change Resident 
Monitor so that it will tab for a KSR33, and send filler 
characters when outputting carriage returns. 


Jnaffacted. 


Unaffected. 


The Interface Routine refreshes this pointer to .DAT. 


'he Interface Routine refreshes this indication of the 
lumber of positive .DAT slots. 


The Interface Routine refreshes this pointer to .UFDT+0. 


When the Nonresident Monitor was the last program, the 
System Loader allocates the number of buffers indicated 
by the contents of .SCOM+26. If the Nonresident Monitor 
was not the last program, the System Loader restores 
.SCOM+26 to the default value if program to be loaded is 
core image. Otherwise, untouched. 


27 

EUB 

rst time initialization routine sets this indica- 
: the number of words per file buffer. 

30 

The Ini 
File Bi: 

.tialization Routine loads this pointer to the 
iffer Transfer Vector Table. 

31 

i 

When loading a core-image program, the Interface Routine 
loads .SCOM+31 with the pointer to the Overlay Table, or 
with zero, if there is none. 

32 

Unaffected. 

33 

1 

I 

| See Interface Routine table, to determine bow that routine 
reacts to the bits in .SCOM+33. 


Unaffected. 


System Loader 1c 
assigned to the 

sads with the number of active .DAT slots 
system device. 

j Unaffected. 


the program to be loaded. 


Unaffected. 


System Loader loads with the number of entries in the 
Mass Storage Busy Table. 


Unaffected. 


System Loader loads with the address of the first entry 
in the Mass Storage Busy Table. 

































Table 4-3 


Use of .SCOM+4 by the System Loader 


If set, place "API ON" constant into 000006 . 

If clear, place "API OFF" constant in same register. 

Ignored. 


If set, change the Resident Monitor so it will tab 
with the KSR 35/37 tabbing mechanism. 


Loader will set this bit, if loading the Nonresident 
Monitor; clear it otherwise. 


Ignored, 


Loader sets this bit if bit 11 is cleared, and load¬ 
ing the Linking Loader or Execute. Otherwise clear. 


Sets or clears, after comparing current core size 
(known by location of Bootstrap, and status of bit 0 , 
.SCOM+2,0) with SGNBLK parameter. Also, modifies 
Resident Monitor to give IOPS77 after attempts to use 
CTRL Q. 



Indicates whether to clear or set bit 7, when loading 
Linking Loader or Execute. 


Ignored 



1* Each .DAT slot will contain a handler number — either the 
system default, or one inserted via an ASSIGN command to 
the Nonresident Monitor. This handler number is the rela¬ 
tive location of the handler name in the IOC Table, which 
the Interface Routine builds. (The IOC Table contains 
handler names in Radix 50 .) 

2. For each active .DAT slot, the loader uses the handler 
number in that slot to find the name in the IOC table, and 
converts the name to .SIXBT. 

3. If the handler is already in core, the loader simply inserts 
the starting address of the handler into the .DAT - slot. 

4. If the handler is not yet in core, the loader does a .SEEK 
to <IOS> UIC for the handler, reads it into core, relocates 
it, and places the starting address of the handler into 
the .DAT slot. 


The System Loader always sets up .DAT-2 and -3. (It reserves .DAT-7 
for its own use.) When not in non-BOSS Batch Mode, -2 is assicmed 
to TTA. In non-BOSS Batch Mode, the batch input device croes to -2. 
If loading the Nonresident Monitor and bit three of .SCOM+42 is set, 

the System Loader will set up .DAT-12 for the LPA, if it is in the 
system, or else for TTA. If in BOSS mode, the Nonresident Monitor 
assigns LPA. to .DAT+6, and the System Loader assigns .DAT-7 to the 
system device "A" handler. The System Loader then ensures that both 
handlers are in core. The Resident BOSS set up routine subsequently 
routes all .DAT slots connected to TTA. to Resident BOSS. 


4.5 BUFFER ALLOCATION BY THE SYSTEM LOADER 

The System Loader allocates space for buffers equal to the contents 
of .SCOM+26 times the contents of .SCOM+27. The first time initial¬ 
ization routine sets .SCOM+27 to the standard number of locations per 
buffer. Before the Nonresident Monitor does an .OVRLA to a software 
system program, it checks whether a BUFFS command has been issued. 

If so, it leaves .SCOM+26 as is. if not, it uses the default number 
of buffers for that program, as shown in SYSBLK. 
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CHAPTER 5 


SYSTEM INFORMATION BLOCKS AND TABLES 


5.1 CORE-RESIDENT NON-REFRESHED REGISTERS 

The .SCOM table, the Bootstrap and the resident Patch Area are the 
only registers not refreshed by the System Loader. Table 5-1 de¬ 
scribes the .SCOM Table. 

5.2 DISK-RESIDENT UNCHANGING BLOCKS; SYSBLK, COMBLK AND SGNBLK 

SYSBLK, COMBLK and SGNBLK occupy blocks 34, 35, and 36 (octal) on the 
system device (unit zero). SYSBLK and COMBLK (blocks 34 and 35) contain 
the parameters for loading all core image system programs. SGNBLK con¬ 
tains all the other information needed to run DOS. All three arrive 
in core along with the Resident Monitor and the System Loader Inter¬ 
face, and start at location 16100 of the highest bank. The Nonresident 
Monitor and System Loader use them, and DOSGEN and PATCH modify them, 
when necessary. 

5.2.1 SYSBLK 

SYSBLK contains the parameters required for implementation of .OVRLA 
to any system program, or any of the system program overlays. 

The order of entries in SYSBLK is unimportant, except for the first 
three permanent entries: RESMON, .SYSLD, and tOAREA. The first word 

of SYSBLK contains the block address (the unrelocated address) of the 
first free word after itself. Figure 5-1 describes SYSBLK. 

5.2.2 COMBLK 

COMBLK contains information the System Loader and the Nonresident 
Monitor need to remember about the current core-image system programs. 
The last location in COMBLK (that is, location 377 of block 35) con¬ 
tains the block address of the first entry in COMBLK. The remainder 
of COMBLK consists of variable-length entries associated with the 
system programs. The Nonresident Monitor searches COMBLK when it 
finds no match for a typed command in its own Command Table. Figure 
5-1 illustrates the organization of COMBLK. The System Generator adds 
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Table 5-1 


. SCOM Registers 


REGIS 

— 

dTER bit 

MEANING 

0 


First register below the Bootstrap (set by the 

System Loader Interface) 

1 


First register above the Resident Monitor (set by 
the System Loader Interface) 

2 


Lowest free register available for storage (set 
by the System Loader or the Linking Loader) 

3 


Highest free register available for storage (set 
by the System Loader, the Linking Loader or DDT) 

4 


Initialized from SGNBLK values by the "first time" 
section of the System Loader Interface Routine, 
and by the LOGIN, LOGOUT and MICLOG logic of the 
Nonresident Monitor; modified by the Nonresident 
Monitor, unless otherwise indicated. 

9 = 1 

API is available. 

1—1 

II 

1—1 

EAE is available (always set) 

2 = 1 

Teleprinter is Model 35 or 37 

3 = 1 

Nonresident Monitor is in core 

4,5 

Reserved 

i—1 

li 

9-Channel Magnetic Tape System 

7 = 1 

Page Mode Operation 

8 = 1 

QAREA inadequate for current core size (set by 
the System Loader Interface Routine) 

9 = 1 

DOS disk file structure (always set) 


H 

'sa 

II 

H 

RB09 disk is system device. 


11 = 1 

Bank Mode System 


12,13 

Line Printer Line Size: 

00 No Line Printer 

01 80 Characters 

10 120 Characters 

11 132 Characters 


14 = 1 

Background/Foreground System (always clear) 


15- 17 

Drum size (ignored — DOS does not support drum) 
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When using the Linking Loader, .SCOM-i-7, 10 and 11 
contain the handler numbers for handlers needed by 
the Linking Loader in .DAT-1, -4, and-5 respectively. 

When the Linking Loader passes control to DDT, 

SCOM-f 10 contains the size of the Busy Table (for 
later clearing by DDT) and .SCOM+11 has the starting 
address of the symbol table. 

When using EXECUTE, 7-11 contain the .SIXBT repre¬ 
sentation of the name and extension of the Execute 
File. 

When using QFILE (for implementation of .GET, .PUT 
and the Nonresident Monitor GET and PUT commands ), 
7-11 contain the .SIXBT representation of the name 
and extension of the core image file. 


API Level 4 service routine entry point 


API Level 5 


API Level 6 


API Level 7 



Program Counter on Keyboard Interrupts. 


AC on Keyboard Interrupts. 


20K or 28K system. 


UC15 system — RK05 based or RF15/RP02 based 


30 CPS LA30 console device. 


First free address in top page 


Magtape Status Register. 


Reserved for Magtape Handler. 


Pointer to .DAT+0. 


Number of positive .DAT slots 


Pointer to .UFDT+0. 


Number of buffers. 


Number of words per buffer 


Pointer to Buffer Transfer Vector Table, 


5-3 





















































Table 5-1 (Cont.) 

„SCOM Registers 

MEANING 

Pointer to first entry in the Overlay Table (zero, 
if none). 

Bad block number on IOPS 2 $ and 72. 

CTRL X status register. 

HALF ON 

Display Buffer already set up. 

VT ON 

If VT ON, display mode is on. . 

If in BOSS mode, elapsed time in seconds. 
Instruction to clear TT Busy Switch. 

Number of Entries in the Mass Storage Busy Table. 
Entry point for Expanded Error Processor. 

JMP to Expanded Error Processor. 

The logged-in UIC. 

Bit Register. 

MICLOG successful. 

.EXIT from Nonresident Monitor. 



Dump core on calls to .MED (except IOPS 4). 
Halt on calls to .MED (except IOPS 4). 

Unused. 

Set up .DAT+6 (use by Batch mode) 

Load System Device Handler into .DAT-7. 

KEEP ON. 

Batch Mode. 

.SIXBT Representation of the name of the core 
image system program to be loaded (if any). 

.SIXBT Representation of the name of the Non¬ 
resident Monitor 

































Table 5-1 (Cont.) 
oSCOM Registers 


REGIS 

1 

TERS BIT 

MEANING 

47 


Date [mm (bits 0-5), dd (6-11), yy (12-17, module 

1970 decimal) ] 

50 


Time [hh (bits 0 - 5 ) , mm (6-11), ss (12-17)] 

51 


Elasped time, in ticks, ~ ~ 

52 


BOSS Bit Register 

'S3 

II 

I-- 1 

BOSS15 Mode. 

1 = 1 

Control Card Read by user, 5/7 ASCII image saved 
m first block of NRBOSS. 

2 = 1 

Resident BOSS reached "EOF" on run time file (RTF) 

3 = 1 

User exceeded time estimate. 

4 = 1 

I/O CAL to go to TTY (. DAT-3 and positive . DAT slots) . 

t — 1 

H 

LD 

Terminal IOPS error by user. 

6 = 1 

QDUMP to be given to user on IOPS errors. 

rH 

II 

Operator abort (Control T). 

rH 

II 

00 

Job active. 

9 = 1 

Exit from B0SS15 Mode, 

10 = 1 

User tried to do a .PUT. Core will be dumped and 
a listing given on LP. 

11 = 1 

User tried to do a .GET. 

12 

Not defined. 

13 

Not defined. 


14-16 

.SYSLD error number. 


17 = 1 

Job abort. 

53 


Reserved for CTRL X code. 

54 


Default Protection Code. 

55 


Entry to Monitor TRAN routine. 

56 


Two's complement of time limit, in seconds (zero, 
if no limit). 

57 


System Device Code, for use by the Linking Loader. 

60 


Number of ticks until clock interrupt specified 
in last .TIMER (zero, if .TIMER not in use). 1 







Table 5-1 (Cont.) 
t 3COM Registers 


REGISTER 


MEANING ] 

61 


.TIMER address. 

62 


Address of the first word in the Mass Storage Busy 
Table. 

63 


Number of words per Mass Storage Busy Table Entry. 

64 


JMP to CTRL Q GET routine. 

65 


QFILE Communication Register. 

6 6 


First Block of the CTRL Q Area. 

67 


Starting Address minus one of the* CTRL Q Area. 

70 


Two’s complement of number of word in Qdump 

71 

|| 

Starting Address after DUMP or GET. 

72 

Hi 

Starting Address after CTRL Q. 

73 


Two’s complement of the number of ticks left in the 
next second. 

74 


Two's complement of the line frequency. 

75 


Number of RTF Lines (for BOSS Mode). 

76* 

0=1 

SPOOLER ENABLED 


1=1 

SPOOLER RUNNING 


3 

5-17 

MAC11 Communication Bit 

SPOOLER area disk start block number 

77* 

6-17 

SPOOLER area size (in blocks) 

100* 

6-17 

pointer to TCB and Buffer Table 

101-105 


unused 


*For RK05 system only. Unused for RP02 and RF15 systems. 
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Wo 

in 

Value 

De 


.SIXBT 
.SIXBT 
nnnnnn 



nnnnn 

addres 


Pointer to first free word after SYSBLK 
(There is one set of seven words/core 
image program.) 

Name of System Program or overlay 

Number of first block on system device 
occupied by this program or overlay. 
Number of blocks occupied by this pro¬ 
gram or overlay 

Thirteen-bit first address for this 
program or overlay 
Program size 

Thirteen-bit starting address for this 
program or overlay 


(free area' 


000010 

.SIXBT 

.SIXBT 

.SIXBT 

.SIXBT 

000002 


.DAT & 7 7 7 
.DATS77 7 

000005 

.SIXBT 
.SIXBT 


. DAT & 7 7 7 


Number of words in this entry (in this 
case, 10) 

Name of this system program (left- 
justified and zero-filled) 

Name of an overlay (left-justified and 
zero-filled) -- overlays are optional 
Number of buffers required by this sys¬ 
tem program (Bits 0-6 = 0 means the end 
of any overlay names. This is why pro¬ 
gram and overlay names must be left- 
justified. ) 

Active .DAT slot 

Active .DAT slot (Note; 777777 for a .Di 
slot means all positive .DAT slots.) 
Number of words for this entry (in this 
case, 5) 

Name of this system program 

Number of buffers required by this pro¬ 
gram (Note that this program has no over¬ 
lays . ) 

.DAT slot for this program 


000500 Pointer to first word in COMBLK (equals 

count from first word in SYSBLK). The 
two contiguous blocks on the system de¬ 
vice that hold SYSBLK and COMBLK are 
treated by the system as one large block 
In this case, COMBLK happens to start at 
location 500 of the two blocks combined. 

Figure 5-1 


SYSBLK and COMBLK 
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names of core-image system programs by making them the new first entry 
In this way, SYSBLK and COMBLK build toward the center. 

5.2.3 SGNBLK 

SGNBLK (block 36 on the system device) contains all the system param¬ 
eters not directly associated with core-image system programs. The 
bulk of SGNBLK is concerned with I/O (.DAT slots, .UFDT slots, Skip 
Chain Order, Handlers, and skip IOT codes and mnemonics). The first 
few registers hold such important system information as the system de¬ 
vice, .SCOM+4 contents, and so on. The very first word in SGNBLK 
points to the block address of the first free word after SGNBLK. The 
next entry is an offset word indicating the total length (including 
itself) of the miscellaneous system parameter table to follow. This 
table includes the size of the .DAT and the size of the skip chain. 

The end of the handler and skip IOT table is the first free entry of 
the block. 

The .DAT slot table corresponds to the legal range of .DAT slots, 
with the maximum negative set to 15 8 and the maximum positive set to 
a number not to exceed 77g a The .DAT slots are in the form in which 
they appear when the Nonresident Monitor is in core. That is, the 
unit number is in bits 0-2, and the number of the handler right- 
justified in bits 3-17. The handler number for the first handler in 
the Device Handler-Skip IOT Table is zero, for the pseudo-handler NON, 
TTA. is one, and so on. The constant 100000 indicates a fixed or il¬ 
legal .DAT slot (such as -2, -3, and p). DOSGEN will not modify Such 

slots. 

The .UFD Table is in one-to-one correspondence with the .DAT slot Table 
An entry of .SIXBT 'UIC' indicates that the logged in UIC is to be sub¬ 
stituted for the name UIC in the table. An entry of .SIXBT 'SYS' in¬ 
dicates BNK or PAG is to be substituted, in accordance with the current 
addressing mode. Otherwise, the contents of each location will be the 
.SIXBT representation of the corresponding .UFD slot. 

The Skip Chain Table lists the system skip IOT's in order. A negative 
skip (one that skips on "off", not "on") is represented in one's com¬ 
plement. Not all skips in the handler Skip IOT Table (described be¬ 
low) need to be included in the Skip Chain Table. 



•* 
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The Device Handler/Skip IOT Table contains all the handler names and 
skip IOT numbers and mnemonics for each I/O device identified to the 
system. Every such device has an entry in the table. A handler name 
must be exactly three characters in length, with the last character 
not an octal digit. The device code for a device is exactly two 
characters. The first two characters of each handler name for a de¬ 
vice must be the device code. This fact is essential for understand¬ 
ing the format of a device entry, since the device code is never 
stored as such in an entry, but is inferred from the device handler 
name. The typical entry for a device is the following; 


The first words of an entry contain the handler names 
for a device m .SIXBT. Each handler name is differ- 

bv ; wSr/w?,^ ° f ^ i iSt ° f handlers is determined 
position?. 26rOS ^ ^~ 5 (thS firSt charact er 

The word that terminated the list of handler names 
contains the number of skip IOT's for the device. 

- fnr^h^L 10,1 ' thSre are threS W ° rdS ln the table; 
o for the skip mnemonic and one for the actual code. 


The next device entry follows the last skip for the previous device. 
Handlers may be entered without any skips, but no devices may be 
entered without at least one handler name. Figure 5-2 illustrates 
the organization of SGNBLK. Appendix D of SGEN-DOS Utility Programs, 
DEC-15-USGNA-A-D, lists SGNBLK, SYSBLK and as tl^T^T^Tied 

by Digital Equipment Corporation. 


5.3 DISK-RESIDENT CHANGING BLOCKS 


The system Loader uses block 37 of the system device to store an image 
of .DAT and .UFDT. other disk-resident changing blocks are the storage 
Allocation Table and the Bad Allocation Table. These tables are de¬ 
scribed in Chapter 6. 


5.4 TEMPORARY TABLES BUILT FROM DISK-RESIDENT TABLES 
5.4.1 The Overlay Table 


The System Loader builds the Overlay Table from the entries in SYSBLK 
referenced by a core-image system program's entry in COMBLK. That is, 
the Overlay Table contains an entry for the system program itself, and 
one for each of its overlays. Figure 5-3 illustrates the format of an 
entry rn the Overlay Table. The first entry in the Overlay Table is 
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Location 

Value 

Description 

0 

000nnn 

Pointer to first free entry in SGNBLK 

1 

000015 

Number of miscellaneous parameters 

2 

000rmn 

Size of .DAT plus size of .UFDT = (number of posi¬ 
tive .DAT slots-f 16 8 ) *2„ (Initial value is 20 8 posi¬ 
tive .DAT slots.) 

3 

000nnn 

Number of skips in Skip Chain 

4 


System device code in .SIXBT 

5 

nnnnnn 

Original contents of .SCOM+4 

6 

nnnnnn 

Original contents of .SCOM+20' 

7 

nnnnnn 

Number of words per buffer (.SCOM+27) 

10 

nnnnnn 

Default number of buffers (.SCOM+26) 

11 

.SIXBT 

Monitor Identification Code 

12 

nnnnnn 

Information on VT and CTRL X (.SCOM-f33) 

13 

00000n 

Default files protection code (.SCOM+54) 

14 

00rmnn 

Size of the Resident Monitor Patch Area 

15 

7777nn 

Minus the number of clock ticks in a second (-74 
for 60 hz, -62 for 50 hz„) 

16 

000nnn 

Device assignments for the .DAT (made by handler 



numbers). (Termination at 53 assumes 20 e positive 

53 

000nnn 

slots.) 

54 

.SIXBT 

UIC assignments for the .UFDT. (Termination at 



111 assumes 20 g positive slots.) 

111 

.SIXBT 


112 

nnnnnn 

Skip Chain Table (Negative skips in one's comple- 



ment.) (Termination at 137 assumes 26 skips in 

chain.) 

137 


nnnnnn 

140 

.SIXBT 

The last part of the SGNBLK is the Device Handler- 



Skip IOT Table. Each entry starts with the .SIXBT 



representations of all handlers for a particular 


STXBT 

device. (First two characters equal device code, 


.SIXBT 

for all handlers.) Zeros in the first six bits 


of a word indicate the end of the handler names, 



and says that the rest of the word contains the 


,STXBT 

number of skips for this entry's device. The skip 


000003 

IOT's follow immediately. As above, one's comple- 


ment skips indicate negative skips. Note, however. 

• 

nnnnnn 

nnnnnn 

.SIXBT 

the confusing fact that a one's complement of a 
skip IOT is a positive number. Thus, 70nnn com- 


plemented is (37nnnn. 

. 

000001 



nnnnnn 


312 


SGNBLK ends at 312, in the DOS-15 RP02 and RF15 
system distributed by Digital Equipment Corporation. 


Figure 5-2 

SGNBLK for RP02 and RF15 Systems 
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.SIXBT 


.SIXBT 


nnnnnn 


nnnnnn 
.SIXBT 


.SIXBT 
.SIXBT 


.SIXBT 

000003 



000001 

nnnnnn 


Pointer to first free entry in SGNBLK 
Number of miscellaneous parameters 
Size of .DAT plus size of .UFDT = (number of 
positive .DAT slots -f 16 8 )*2 a (Initial value 
is 2j2f e positive .DAT slots.) 

Number of skips in Skip Chain 
System device code 
Original contents of .SCOM+4 
Original contents of .SCOM4-20’ 

Number of words per buffer (.SCOM+27) 

Default number of buffers (.SCOM+26) 

Monitor Identification Code 
Information on VT and CTRL X (.SCOM+33) 
Default files protection code (.SCOM+54) 

Size of the Resident Monitor Patch Area 
Minus the number of clock ticks in a second 
(-74 for 60 hz , -62 for 50 hz) 

Spooler area last block number. 

Spooler area size. 

Device assignments for the .DAT (made by 
handler numbers). (Termination at 55 assumes 
20 8 positive slots.) 

UIC assignments for the .UFDT. (Termination 
at 113 assumes 20 positive slots 3 ) 


Skip Chain Table (Negative skips in one's 
complement.) (Termination at 145 assumes 
32 skips in chain,.) 

The last part of the SGNBLK is the Device 
Handler-Skip IOT Table. Each entry starts 
with the .SIXBT representations of all 
handlers for a particular device. (First two 
characters equal device code, for all 
handlers.) Zeroes in the first six bits of 
a word indicates the end of the handler 
; names, and says that the rest of the word 
| contains the number of skips for this entry's 
^device. The skip IOT's follow immediately. 
l As above, one's complement skips indicate 
j negative skips. Note, however, the confusing 
I fact that a one's complement of a skip IOT 
i is a positive number. Thus, 70nnnn comple- 
j mented is 07nnnn« 


SGNBLK ends at 344, in the DOS-15 RK05 
system distributed by Digital Equipment 
Corporation. 
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pointed to by .SC0M+31. .SCOM+31 will contain zero, if there are no 
entries in the Overlay Table. This will occur during Linking Loader 
or EXECUTE loads. 


.OVRLA is the only Monitor function that looks at the Overlay Table. 

If the .OVRLA processor finds a match to the .OVRLA argument in the 
Overlay Table, it uses the parameters listed in the table to bring 
it in via a Monitor TRAN. Note that this bypasses the System Loader, 
and does not change the handler load. Thus, the overlay must use only 
those .DAT slots required by the original program, the one listed in 
COMBLK. 

If the .OVRLA processor does not find a match in the Overlay Table, it 
calls in the System Loader, which searches COMBLK for the requested 
program. This type of overlay request does not require that .DAT slot 
assignments be the same. On the other hand, the System Loader refreshes 
all of core except .SCOM, etc. Thus, communication between overlays 
is more difficult. The resident patch area, however, can be used for 
this purpose. 

5.4.2 The Device Table 

The Device Table is built by the System Loader interface whenever PIP 
is being loaded, or when PIP is listed in COMBLK among the overlays 
for a program. It is located just above the register pointed to by 
.SCOM+1, and has an entry for each positive .DAT slot. If a slot has 
an assigned device, the low-order twelve hits of the corresponding 
entry in the Device Table will contain the device's code, in .SIXBT. 

Bit 3 is set when the slot is busy. if no device is assigned to a 
slot, the corresponding entry in the Device Table will contain zero. 

5.4.3 The Input/Output Communication (IOC) Table 

The System Loader Interface builds the IOC Table and locates it just 
below the first register of the System Loader. It contains an entry 
for each handler in the system, in the order that they appear in 
SGNBLK. The entries themselves contain the handler name in Radix 50. 

The System Loader and the Linking Loader use the handler number sup¬ 
plied by the Nonresident Monitor to index down the IOC Table. They 
use the contents of the entry for a .SEEK to the IOS UIC. 



5» 4» 4 The Device Assignment Table (.DAT) 






The Device Assignment Table makes the association between logical and 
physical devices. The Monitor knows its location by the contents of 
* SCOM4-23 , which points to the entry zero in the Table. Specific slots 
are found by indexing on the contents of .SCOM4-2 3. The number of nega 
tive slots is fixed at 15 g . The number of positive slots is specified 
by .SCOMH-2 4, and may be any positive number less than 100 it is 
specified at system generation time. 


The Nonresident Monitor places the handler number in the low order 
bits and the unit number in the high order bits. It derives the hand¬ 
ler number from SGNBLK. As mentioned above, the System Loader and 
the Linking Loader subsequently use the IOC Table to determine the 
handler name. After either loader has loaded and relocated a handler, 
it places the handler's starting address in all .DAT slots that refer¬ 
ence that handler. The unit number remains in the high-order three 
bits. Slots with no handler (NON) contain zero. Active .DAT slots 
are designated by COMBLK, for core-image system programs, and by .IODEV 
pseudo-ops for the Linking Loader and EXECUTE. 

5.4.5 The User File Directory Table (.UFDT) 


.UFDT+0 is offset from .DAT+0 (pointed to by .SCOM+23) by the sum of 
the positive and negative .DAT slots. Each .DAT slot has a correspond¬ 
ing .UFDT slot. UIC's in the .UFDT are packed in .SIXBT. The address 
of .UFDT+0 is stored in .SCOM+25. 


5.4.6 The Skip Chain 

Register 1 of Bank 0 contains a jump to the beginning of the Skip 
Chain. The Skip Chain is defined during System Generation, is located 
in SGNBLK, and is rebuilt every time the System Loader is called in. 

The System Generator Manual (DEC—15-USGNA-A-D) describes considerations 
for constructing the Skip Chain. 

5.5 TEMPORARY TABLES BUILT FROM SCRATCH 
5.5.1 File Buffer Transfer Vector Table 


The System Loader allocates space for the buffer pool, and creates the 
File Buffer Transfer Vector Table. .SCOM+30 points to the first entry 
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in the table, and the number of entries is specified by .SCOM+26. 

Each entry in the table contains the address of a buffer, or its one's 
complement. Negative addresses indicate a busy buffer. Since refer¬ 
ences to buffers must be indirect anyway, buffers are allocated with¬ 
out regard to bank boundaries. 

5.5.2 The RCOM Table 


The Nonresident Monitor requires certain information about the Resi¬ 
dent Monitor that does not warrant reserving additional ,SCOM registers 
The System Loader therefore puts this information into the RCOM table, 
whenever it is loading the Nonresident Monitor. The RCOM Table starts 
at register 17500 of the highest bank. QFILE uses the RCOM Table when 
processing a GET command. 

5.5.3 The Mass Storage Busy Table 

Entries in this table are allocated by the System Loader or the Link¬ 
ing Loader. The Mass Storage Busy Table is pointed to by .SCOM+62. 

•SCOM+63 contains the number of words per entry in the table, and 
.SCOM+36 contains the current number of entries. Generally speaking, 
there are as many entries in the Busy Table as there are active .DAT 
®iots, although the disk handlers are the only ones that currently 
refer to the Busy Table. 

The .INIT command to a disk handler establishes a Busy Table entry. 

The .CLOSE command (or the Rewind .MTAPE command) deletes the corres¬ 
ponding entry. Figure 5-4 illustrates a typical Busy Table Entry. 

The first word of an active entry in the Busy Table contains the .DAT 
slot in bits 9-17. The disk handlers save information about the UFD 
current for this .DAT slot in the Mass Storage Busy Table. They save 
information about the file current to the .DAT slot (if any) in the 
buffer pointed to by word 1 of the Busy Table Entry. More information 
on the disk handlers and file structure is contained in Chapter 6. 


5.6 RESERVED WORD LOCATIONS 


Word locations 0 through 77 are dedicated systems locations and can 
not be employed by the user. The contents of these locations are 
described in Table 5-4. 
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N,N+1 

.SIXBT name of Overlay 

N+2 

First block number 

N+3 

First address, minus 1 

N+4 

Size, in two's complement 

N+5 

Fifteen-bit starting address 


Table 5-3 

Mass Storage Busy Table Entry 


Word # 

Contents 

N 

Device Type^_ 2 , Unit Number^, Write Cheeky,»DAT g _ 17 

N+l 

Buffer Address, or J2f, if none allocated 

N+2 

Three-character UIC 

N+3 

First UFD block for this UIC 

N+4 

UFD Entry size for files in this UFD 


Table 5-4 

Reserved Address Locations 


ADDRESS 

USE 

0 

Stores the contents of the extended PC, link, extend 
mode status, and memory protect status during a pro¬ 
gram interrupt 

1 

EEM (for PDP-9 compatibility) 

2 

JMP to Skip Chain 

3 

.MED, entry to Monitor Error Diagnostic routine 

4 

JMP to error handler 

5 

Stores system type (Bank or Page) indicator during 
Teletype interrupts 

6 

Used for API ON/OFF indicator 

7 

Stores real time clock count 

10-17 

Autoindex registers 

20 

Stores the contents of the extended PC, link, mode 
status, and memory protect status on a CAL instruc¬ 
tion . 

21 

JMP to CAL handler 

22-37 

Seven pairs of word counter-current address registers 
for use with 3-cycle I/O device data channels. 

40-77 

Store unique entry instructions for each of 32 „ auto¬ 
matic priority interrupt channels 
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5.7 BOOTSTRAP NON-BOSS BATCH BITS. 

The high-order three bits of word 17777 in the Bootstrap are reserved 
for the Monitor, and have the following meanings: 

Bit 0 1 = In non-BOSS Batch Mode 

0 = Not in non-BOSS Batch 

Bit 1 1 = $JOB ASCII line or card just read by batch device 

0 = Last line or card not $JOB 

1 = Batch device is card reader 

2 = Batch device is paper tape reader 


Bit 2 



CHAPTER 6 


FILE STRUCTURES 


6.1 DECTAPE FILE ORGANIZATION 


DECtape can be treated either as a directoried or non-directoried 
device. 


6.1.1 Non-Directoried DECtape 


A DECtape is said to be non-directoried when it is treated ?s magnetic 
tape by issuing the .MTAPE commands; REWIND or BACKSPACE, followed by 
• READ or .WRITE. No directory of identifying information of any kind 
is recorded on the tape. A block of data (255 1Q word maximum), exactly 
as presented by the user program, is transferred into the handler 1 of¬ 
fer and recorded at each .WRITE command. A .CLOSE terminates record• 
ing with a software-end-of-file record consisting of two words? 00101".. 
776773 


Because braking on DECtape allows for tape roll, staggered recording 
of blocks is employed in DOS to avoid constant turnaround or time- 
consuming back and forth motion of physically sequential block record¬ 
ing. When recorded as a non-directoried DECtape, block 0 is the 
first block recorded in the forward direction. Thereafter, every fifth 
block is recorded until the end of the tape is reached, at which time 
recording, also staggered, begins in the reverse direction. Five 

passes over the tape are required to record all 1100 n blocks, 

o 


6.1.2 Directoried DECtape 


Just as a REWIND or BACKSPACE command declares a DECtape to be non- 
directoried, a .SEEK or .ENTER implies that a DECtape is to be con¬ 
sidered directoried. A directory listing of any such DECtape is 
available via the (L)ist command in PIP. A fresh directory may be 
recorded via the N or S switch in PIP. 


The directory of all DECtapes except system tapes occupies all 400 o 

O 

words of block 100 . It is divided into two sections: (1) a 40 o word 

o o 

Directory Bit Map and (2) a 340g word Directory Entry Section. 



The Directory Bit Map defines block availability. One bit is allo¬ 
cated for each DECtape block (llOOg bits = 40g words). When set to 1, 
the bit indicates that the DECtape block is occupied and may not be 
used to record new information. 

The Directory Entry Section provides for a maximum of 56 1Q files on 
a DECtape. Each file on the DECtape has a four-word entry. Each 
entry includes the three—word file name and extension, a pointer to 
the first DECtape block of the file, and a file active or present bit. 
Figure 6-1 illustrates the DECtape directory. 



Directory 
Bit Mao 


Directory 

Entry 

Section 


9 5 6 _11 12_17 


File 


I 

Name 


File Name Extension 

1 

Data Link (First File Block) 


Sign Bit: 1 = File Active 


Note: Nulls (0) fill 
in short file names. 

A file name extension 
is not absolutely 
necessary. 


A DIRECTORY ENTRY 


Figure 6-1 
DECtape Directory 

Additional file information is stored in blocks 71 through 77 of every 
directoried DECtape. These are the File Bit Map Blocks. For each file 
in the directory, a 40g-word File Bit Map is reserved in block 71 
through 77. The bit maps are contiguous, and the N th file uses the 


6-2 




N bit map. Each block is divided into eight File Bit Map Blocks. A 
File Bit Map specifies the blocks occupied by that particular file and 
provides a rapid, convenient method to perform DECtape storage re¬ 
trieval for deleted or replaced files. Note that a file is never de¬ 
leted until the new one of the same name is completely recorded on 
the .CLOSE of the new file. When a fresh directory is written on 
DhCtape, blocks 71 through 100 are always indicated in the Directory 
Bit Map as occupied. Figure 6-2 illustrates DECtape file bit maps. 


Block 71 0 

O 

Block 72 0 

O 


Block 77g 


Bit 

Map 

for 

File 

0 

Bit 

Map 

for 

File 

7 

Bit 

Map 

for 

File 

8 

Bit 

Map 

for 

File 

15 10 

• 

Bit 

Map 

for 

File 

4B m 





§« 

Bit 

Map 

for 

File 

®i0 


Figure 6-2 

DECtape File Bit Map Blocks 


Staggered recording (at least every fifth block) is used on directoried 
DECtapes, where the first block to be recorded is determined by examina¬ 
tion of the Directory Bit Map for a free block. The first block is 

always recorded in the forward direction; thereafter, free blocks are 
chosen which are at least five beyond the last one recorded. The last 
word of each data block recorded contains a data link or pointer to 
the next block in the file. When turnaround is necessary, recording 
proceeds in the same manner in the opposite direction. When reading, 
turnaround is determined by examining the data link. If reading has 
been in the forward direction, and the data link is smaller than the 
last block read, turnaround is required. If reverse, a block number 
greater than the last block read implies turnaround. 

A software end-of-file record (001005, 776773) terminates every file. 

The data link of the final block is 777777. 
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Data organization for each I/O medium is a function of the data modes. 

On directoried DECtape there are two forms in which data is recorded: 

(1) packed lines - IOPS ASCII; IOPS Binary, Image Alphanumeric, and 
Image Binary, and (2) dump mode data - Dump Mode. 

In IOPS or Image Modes, each line (including header) is packed into 
the DECtape buffer. In IOPS Binary, a 2's complement checksum is com¬ 
puted and stored in the second word of the header. When a .WRITE 
which will exceed the remaining buffer capacity is encountered, the 
buffer is output, after which the new record is placed in the empty 
buffer. No record may exceed 254 10 words, including header, because 
of the data link and even word requirement of the header word pair 
count. An end-of-file is recorded on a .CLOSE. It is packed in the same 
manner as any other line. 


In Dump Mode, the word count is always taken from the I/O macro. If 
a word count is specified which is greater than 255 1Q (note that space 
for the data link must be allowed for again), the DECtape handler will 
transfer 255 10 word increments into the DECtape buffer and from there 
to DECtape. If some number of words less than 255 10 remain as the 
final element of the Dump Mode .WRITE, they will be stored in the DEC¬ 
tape buffer, which will then be filled on the next .WRITE, or with an 
EOF if the next command is .CLOSE. DECtape storage is thus optimized 
in Dump Mode since data is stored back-to-back. See Appendix A. 

6.2 MAGNETIC TAPE 

DOS provides for industry-compatible magnetic tape as either a di¬ 
rectoried or non-directoried medium. The magnetic tape handlers com¬ 
municate with a single TC-59D Tape Control Unit (TCU). Up to eight 
magnetic tape transports may be associated with one TCU; these may 
include any combination of transports TU-10A or B and TU-30A or B. 

There are a number of major differences between magnetic tape and DEC¬ 
tape or Disk; these differences affect the operation of the device 
handlers. Magnetic tape is well suited for handling data records of 
variable length. Such records, however, must be treated in serial 
fashion. The physical position of any record may be defined only in 
relation to the preceding record. Three techniques available in I/O 
operations to block-addressable devices are not honored by the magnetic 
tape handlers: 
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a. The user cannot specify physical block numbers for 
transfer. In processing I/O requests that have block 
numbers in their argument lists (i.e., .TRAN) the 
handler ignores the block-number specification. 

b. The only area open for output transfers in the direc- 
toried environment is that following the logical end 
of tape. 

c» Only a single file may be open for transfers (either 

input or output) at any time on a single physical unit. 

6.2.1 Non-directoried Data Recording (MTF) 

M.TF is intended to satisfy the requirements of the FORTRAN programmer 
while still providing the assembly language programmer maximum freedom 
on the design of his tape format. MTF writes out a record to the tape 
each time the main program issues a .WRITE. The length of the record 
is always two times the word pair, count in the header word pair. FIOPS 
records are always as long as the buffer size returned on a .INIT (up 
to 256 1q words). MTF returns a standard buffer size of 377 g , after a 
.INIT. The FORTRAN user may dynamically change this size, however, 
via the following instructions 


Example s 


(FORTRAN STATEMENTS) 


SETMTB 

CALL SETMTB (IBFSIZE) 

IBFSIZE 

START 


(MACRO 

STATEMENTS) 

.TITLE 

SETMTB 

.GLOBL 
0 

.DA, MTBSIZ, SETMTB 

JMS* 

.DA 

JMP 

0 

START 

LAC* 

BUFSIZ (any buffer 

DAC* 

MTBSIZ 

JMP* 

.END 

SETMTB 


6.2.2 Directoried Data Recording (MTA., MTC.) 

The programmer can make the fullest possible use of those features 
peculiar to magnetic tape by using MTF. On the other hand, MTF does 
not offer the powerful file-manipulation facilities available in the 
system. Directoried I/O allows device independence, and extensive 
use of the storage medium with a minimum of effort. 


MTA. and MTC. do not support non-directoried data recording. 




Every block recorded by MTA. (with the exception of end-of-file markers, 
which are hardware-recorded) includes a two-word Block Control Pair 
and not more than 255 -^q words of data. The data will contain the 
records from one or more .WRITE's. 

The Block Control Pair serves three functions: it specifies the char¬ 
acter of the block (label, data, etc.), provides a word count for the 
block, and gives an 18-bit block checksum. The Block Control Pair has 
the following format: 


Word 1: 


Bits 0 through 5: Block Identifier (BI). This 6-bit byte 
specifies the block type. Values of BI may range from 0 
to 77„- Current legal values of BI, for all user files, 
are as follows: 


BI Value 


Block Type Specified 


00 

10 

20 


User-File Header Label 
User-File Trailer Label 
User-File Data Block 


Bits 6 through 17: Block Word Count (BWC). This 12-bit 
byte holds the 2 ! s complement of the total number of words 
in the block (including the Block Control Pair). Legal 
values of BWC range from -3 to -401_. 


Word 2: 


Bits 0 through 16: Block Checksum. The Block Checksum is 
the full-word, unsigned, 2's complement sum of all the 
data words in the block and word 1 of the Block Control 
Pair. 


N-2 DATA 
WORDS 



N TOTAL WORDS 
IN BLOCK 


Figure 6-3 


Block Format, File-Structured Mode 
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One of the main file functions of MTA. and MTC. is that of identifying 
and locating referenced files. This is carried out by two means: 
first, names of files recorded are stored in a file directory at the 
beginning of the tape? and second, file names are contained in the 
file's header and trailer labels. 


6.2.2.1 Magnetic Tape File Directory 


The directory, a single-block file (and the only unlabeled file on any 
file-structured tape), consists of the first recorded data block on 
the tape. It is a 257 1Q word block with the following characteristics? 


a. Block Control Pair (words 1 and 2) 

Word 1 

Block Identifier = 74 g = File Directory Data Block 

Block Word Count = -401 o = 7377„„ 

O O 

Word 2: 

Block Checksum? As described above. 

b• Active File Count (Word 3, Bits 9 through 17) 9-bit one's 
complement count of the active file names present in the 
File Name Entry Section (described below). 

c. Total File Count (Word 3, Bits 0 through 8) 9-bit one's 
complement count of all files recorded on the tape, in¬ 
cluding both active and inactive files, but not the file 
directory block. 

d. File Accessibility Map (Words 4 through 17): The File 

Accessibility Map is an array of 252-, g contiguous bits 
beginning at bit 0 of word 4 and ending as bit 17 of 
word 17. Each of the bits in the Accessibility Map re¬ 
fers to a single file recorded on tape. The bits are 
assigned relative to the zero^* 1 file recorded? that is, 
bit 0 of word 4 refers to the first file recorded? bit 
1, word 4, to the second file recorded; bit 0, word 6, 
to the 37 10 th file recorded; and so on, for a possible 
total of 252 1q files physically present. 

A file is only accessible for reading if its bit in the 
Accessibility Map is set to one. A file is made inac¬ 
cessible for reading (corresponding bit = 0) by a .DLETE 
of the file, by a .CLOSE (output) of another file of the 
same name, or by a .CLEAR. A file is made accessible for 
reading (corresponding bit =1) by a .CLOSE (output) of 
that file. Operations other than those specified above 
have no effect on the File Accessibility Map. 
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e. File Name Entry Section (Words 18 through 257); The File 
Name Entry Section, beginning at word 18 of the direc¬ 
tory block, includes successive 3-word file name entries 
for a possible maximum of 80 entries,, Each accessible 
file on the tape has an entry in this section. Entries 
consist of the current name and extension of the refer¬ 
enced file in .SIXBT (left-adjusted and, if necessary, 
zero-filled). 

The position of a file name entry relative to the begin¬ 
ning of the section reflects the position of its accessi¬ 
bility bit in the map. That bit, in turn, defines the 
position of the referenced file on tape with respect to 
other (active or inactive) files physically present. Only 
active file names appear in the entry section, and access¬ 
ibility bits for all inactive files on the tape are always 
set to zero; accessibility bits for all active files are 
set to one. 

To locate a file on the tape having a name that occupies 
the second entry group in the File Name Entry Section, 
the handler must (a) scan the Accessibility Map for the 
second appearance of a 1-bit, then (b) determine that bit’s 
location relative to the start of the map. That location 
specifies the position of the referenced file relative to 
the beginning of the tape. The interaction of the File 
Name Entry Section and the Accessibility Map are shown 
in Figure 6-4. 


6.2.2.2 User-File Labels 


Associated with each file on tape is one label, the header label. It 
precedes the first data block of the file. Each label is 27 10 words 
in length. Label format is shown in Figure 6-5. 


0 5 6 



Figure 6-5 


User File Header Label Format 
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6.2.2.3 File-Names in Labels 

The handler will supply the contents of the file-name fields (Word 3) 
in labels. These are used only for control purposes during the execu¬ 
tion of .SEEK's. The name consists simply of the two's complement of 
the position of the recorded file's bit in the Accessibility Map; the 
"name” of the first file on tape is 111111, that of the third file is 
111115, and so on. A unique name is thus provided for each file physi¬ 
cally present on the tape. Since there may be a maximum of 252^^ files 
present, legal file-name values lie in the range 777777 to 777404. 

6.2.3 Continuous Operation 


Under certain circumstances, it is possible to perform successive I/O 
transfers without incurring the shut-down delay that normally takes 
place between blocks. The handler stacks transfer requests, and thus 
ensures continued tape motion, under the following conditions: 


a. The I/O request must be received by the CAL handler be¬ 
fore a previously-initiated I/O transfer has been com¬ 
pleted . 

b. The unit number must be identical to that of the pre¬ 
viously initiated I/O transfer. 

c. The I/O request must be one of those listed below to 
ensure successful completion. The handler in process¬ 
ing requests in continuous mode depends on receiving 
control at the CAL level in order to respond to I/O 
errors. The functions for which continuous operation 

is attempted include only the following: 

1. .MTAPE 3.- .WRITE 

2. .READ 4. .TRAN 


d. 


e. 


With MTA, more than one logical record may be in a physical 
block, so tape motion may stop if fewer successive .READ'S 
or .WRITE's are issued than there are records in a block. 


The previously-requested transfer must be completed with¬ 
out error. In general, successive error-free READ'S 
(WRITE's) to the same transport will achieve non-stop 
operation. The following examples illustrate this prin¬ 
ciple. 

Example 1: Successful Continued Operation 


SLOT = 1 
INPUT = 0 
BLOKNO = 0 

READ1 .TRAN SLOT, INPUT, BLOCKNO, BUFFI, 257 

READ2 .TRAN SLOT, INPUT, BLOCKNO, BUFF2, 257 

RETURN JMP READl 
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The program segment in Example 1 will most probably keep the refer¬ 
enced transport (.DAT slot 1) up to speed. The probability decreases 
as more time elapses between READ1 and READ2, and between READ2 and 
RETURN. Each .TRAM request causes an implicit .WAIT until its opera¬ 
tion is completed. 


Example 2% Unsuccessful Continued Operation 


SLOT = 1 
INPUT = 0 
BLOKNO = 0 
READ 
STOP 
RETURN 


.TRAN SLOT, INPUT, BLOKNO, BUFF, 257 
.WAIT SLOT 
JMP READ 


The program segment in Example 2 will not keep the tape moving because 
the .WAIT at location STOP prevents control from returning to location 
READ until the transfer first initiated at READ has been completed. 

Example 3: Unsuccessful Continued Operation 

SL0T1 = 1 
SLOT2 = 2 
INPUT = 0 
BLOKNO = 0 
READl 
READ 2 
RETURN 

This program segment will not provide non-stop operation because of 
the differing unit specification at READl and READ2. 

6.2.4 Storage Retrieval on File-Structured Magnetic Tape 

The use of a file accessibility map as well as block identifiers in 
Magtape file directories makes it almost impossible to retrieve the 
area of a deleted file from a magnetic tape. The execution of the 
deletion command (i.e., .DLETE) removes the name of the object file 

from the file directory, and clears the corresponding bit in the File 
Accessibility Map. 

The only circumstance under which a file area may be easily retrieved 
is when the deleted file is also the last file physically on the tape. 
Under these conditions, the handler can retrieve the area occupied by 
the deleted file when the next .ENTER - .WRITE - .CLOSE sequence is 
executed. Users may also copy the active files to another device, re¬ 
new the directory, and recopy the files. 


.TRAN SL0T1, INPUT, BLOKNO, BUFFI, 257 
.TRAN SL0T2, INPUT, BLOKNO, BUFF2, 257 
JMP READl 
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6,3 DISK FILE STRUCTURE 
6.3,1 Introduction 


The DOS-15 disk file structure is in some ways analogous to DECtape 
file structure. Ordinarily, each disk user has a directory which 
points to named files, just as each DECtape has a directory. The DEC¬ 
tape has only one directory, but the disk has as many directories as 
users have cared to establish. A single user's disk directory might 
correspond to a single DECtape directory. A single disk file's size 
is also limited only by the available space, as is true with DECtape. 
Although DECtape directories may reference a maximum of 56 1Q files, the 
number of files associated with any one directory on the disk is limited 
only by the available disk space. 


The DECtape directory is in a known location — at block 100. Since 
the disk may have a variable number of directories, the Monitor must 
know how to find each user's directory. It therefore maintains a 
Master File Directory (MFD) at a known location 1 , and the Master File 
Directory points to each User File Directory (UFD). DOS-15 allows 
only those users who know the Master Identification Code to have ac¬ 
cess to any protected UFD's within the MFD. Figure 6-6 illustrates 
the MFD. Appendix B is a flowchart of the Disk "A" Handlers. 

6.3.2 User Identification Codes (UIC) 


The Monitor finds User File Directories by seeking associated User 
Identification Codes (UIC's), which are all listed in the Master File 
Directory. The UIC is a three-character code that is necessary for 
all non-.TRAN I/O to the disk. .TRAN macros use no directory refer¬ 
ences. A programmer may operate under as many UIC's as he wishes, pro 
vided all are unique and none is reserved 2 . He may establish a new 
User File Directory by (1) logging in his new UIC to the Monitor via 
the LOGIN command, (2) calling pip, and (3) issuing an N DK command. 
This establishes a new User File Directory, or refreshes (wipes clean) 
an old directory under that UIC. (.ENTER will also create a new MFD 
entry and/or a UFD, if none exists.) Figure 6-7, User File Directory, 
illustrates the organization of a UFD. 


On the RF and RK disk, the first block of the MFD is 1777 octal 
2 ° n t S e 1 ? P dlsk ? the first block of the MFD is 47040 octal. 

The following are reserved UIC's: ???, PAG, BNK, SYS, IOS , CTP 
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1 

1 

Contents 

Description 

J2 

777777 

Dummy UIC used by system. 

1 

nnnnnn 

Bad Allocation Table’s first block number, j 

or 777777, if there is none. 1 

2 

nnnnnn X v 

SYSBLK's first block number, or -1, if 
there is none. 

3 

4 rt _-f-blknum 

0-2 

MFD entry size in bits 0-2, plus the block “j 

: 

number of the first submap I 

4N 

. SIXBT 

UIC for this UFD 

I 4N4-1 

nnnnnn 

Block number for the first block of this 

UFD or 777777, if no UFD exists (as after i{ 

PIP’S NtjDKj) j 

4N+2 

V M 

Protection code in bit 0, plus the UFD 
entry size for each file t -0 

4N+3 

spare 

Unused at this writing jj 

376 

nnnnnn 

Pointer to previous MFD block, or 777777 j 

if none. 1 

377 

nnnnnn 

Pointer to next MFD block, or 777777 if 1 



none. ji 


Figure 6-6 


Master File Directory 


Word # 

Contents 

Description 

8N 

.SIXBT 

Name of this file 

8N+1 

.SIXBT 

and its 

8N+2 

.SIXBT 

extension 

8N+3 

T^+blknum 

Truncation code in bit 0, plus the number 
of the first block of the file 

8N+4 

nnnnnn 

Number of blocks in this file 

8N+5 

ribptr 

Pointer to the first block of the Retrieval 
Information Block 

8N+6 

P^_l+ribwrd 

Protection code in bits 0-1, plus the 
first word in ribptr used by the RIB— if 
the last block of the file has room for 
the RIB, the handlers will put it there, f 

and load word 8N+6 accordingly. : 

8N+7 

crdate 

Date of file’s creation -mmddyy (yy modulo 70) 

1 376 

nnnnnn 

Pointer to previous block, or 777777 if none j 

j 377 

nnnnnn 

Pointer to next UFD block, or 777777 if none I 



| 


Figure 6-7 


User File Directory 
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6.3.3 Organization of Specific Files on Disk 

The Disk Handlers write out files in almost the same way that a DEC- 
tape handler does. Disk file blocks, however, have a forward and 
backward link. (Non-dump records are therefore limited to lengths 
of 254 1q words.) Further, upon receipt of a .CLOSE I/O macro, the disk 
handlers fill out a Retrieval Information Block (RIB). The RIB per¬ 
forms the same functions as the file bitmap on DECtape, and also as¬ 
sociates the logical sequence of blocks in the file with the physical 
locations of the blocks on the disk. The disk handler uses the RIB to 
implement .RTRAN commands and to delete files. Figure 6-8, The Retrieval 
Information Block, illustrates a RIB. 

After a user has created a disk file he can access logical records 
sequentially via .READ commands, just as with DECtape files. He can 
also access physical blocks of that file by referencing relative block 
numbers in the .RTRAN command. (The .RTRAN commands require the file 
be opened with the .RAND command.) 

6.3.4 Buffers 

The handlers break buffers from the pool into three parts: (1) File 

Information (about 4words)* (2) the Block List — addresses of 

O 

pre-allocated blocks (between 4 and 253^ addresses, inclusive), and 
(3) data buffer (256^ words). Figure 6-9, Disk Buffer, illustrates 
the breakdown of disk buffers. 

6.3.4.1 Commands That Obtain And/or Return Buffers 

The following commands obtain buffers from the pool, and return them 
immediately after execution: 

.DLETE 
.RENAM 
.CLEAR 

The following commands obtain a buffer from the pool and do not return 
it until a subseauent .CLOSE is performed: 

.FSTAT 
.ENTER 
. SEEK 
.RAND 


*This number is determined by assembly parameters. 
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Word # 

Contents 

Description 

0* 

nnnnnn 

Total number of blocks described by this 
physical block. 

1 

nnnnnn 

First data block pointer. 

2 

nnnnnn 

Second data block pointer. 

3 

nnnnnn 

Third data block pointer. 

376 

nnnnnn 

Pointer to previous RIB block or -1 if no 
previous RIB block. 

377 

nnnnnn 

Pointer to next RIB block or -1 if no 



next RIB block. 

" 11 1 ' . .- 

* Zero word of the RIB may not be zero th word of physical block 

This occurs whenever the entire RIB will fit in the last data 

I block of 

the file. 

_ 


Figure 6-8 

Retrieval Information Block 




File Information becomes 
'Current Set' when file active 
(see 6„3.4.2). 


Addresses of Preallocated 
Blocks (Block List or Temp 
List or TLIST) 


Data Buffer 


*This is not a fixed number. It is 
different for RP, RK and RF. 

Figure 6-9 
Disk Buffer 


40 g Words* 


More than 3 and 
less than 377 
words 


8 


400g Words 
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The following commands return a buffer to the pool, if any was allo¬ 
cated c 

. INIT 
.CLOSE 

,MTAPE (rewind) 

6.3.4.2 The Current Set 

The handlers retain information about the last file and .DAT slot 
processed in an internal storage area. This area is called €he 
"Current Set", and is swapped back to the file's buffer whenever a 
command to a different file is used. Thus, 

.WRITE to .DAT Slot A 
.WRITE to .DAT Slot B 

will swap the Current Set, but... 

.WRITE to .DAT Slot A 
.TRAN to .DAT slot A 
.WRITE to .DAT Slot A 

will not swap the Current Set. 

6.3.5 Pre-allocation 

The handlers pre-allocate blocks on the disk upon all .ENTER commands, 
and whenever sufficient .WRITE commands have been issued to use up the 

pre-allocated blocks. The number of pre-allocated blocks will be the 
minimum of the number of free blocks on the device and the number of 
address slots available in the Temp List (block list). 

When the handlers pre-allocate blocks, they fill out the bit maps, and 
immediately fill out the RIB and write it out in one of the pre-allocated 
blocks, 


Upon a .CLOSE command, the handlers give back unused blocks, and re¬ 
write the RIB. 
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The number of blocks in the Block List depends on the size of the 
buffer f which is determined at system generation by setting the buffer 
size- The larger the Block List, the faster will be output,, Smaller 
Block Lists may give more efficient allocation of core and disk space. 
Smaller buffers save core. Further, the number of pre-allocated blocks 
may affect concurrently opened files on a disk that is tight for space. 
Thus, if the Block List is sixty entries long, and there are forty 
blocks left on the disk, a .ENTER to .DAT slot will pre-allocate all 
forty, leaving none for any subsequent .ENTER's to different .DAT 
slots. 

IOPS 70 will occur when there are less than four free blocks on the 
disk when a handler tries to pre-allocate blocks. 


6.3.6 Storage Allocation Tables (SAT's) 1 


The disk handlers use a Storage Allocation Table, in order to distin¬ 
guish between allocated and free blocks. If more than one physical 
block is required, the individual blocks are called Submaps. 

Unlike DECtape, the Storage Allocation Table is never held in core. 
When the handlers wish to preallocate some blocks, they read in the 
required Submap, and write out the updated one. 


Storage Allocation blocks use the following formats 


WORD 0 
WORD 1 

WORD 2 

WORD 3 


Total blocks on the disk 
Number of blocks described 
by this Submap 
Number of blocks occupied 
in this Submap 

First word of the hit map 
(eighteen blocks per word) 


WORD 376 Pointer to previous Submap 

(or 777777) 

WORD 377 Pointer to next Submap 

(or 777777) 


The bit maps refer to blocks in numerical order. Thus, bit 0 of word 
three of a Submap will refer to block N, bit 1 will refer to block N+l, 
and so on. The block is free if the corresponding bit equals 0 . Start¬ 
ing and ending block numbers for all Submaps are retained in the hand¬ 
lers, Bit 0 of word three in the first submap, refers to block zero. 

X The first SAT block is located at 1776„ for the RF and RK system and 
764g for the RP system , 
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6=3.7 Bad Allocation Tables (BAT's) 

Occasionally? a particular block on the disk will not record data cor¬ 
rectly. In such instances, the handlers should be prevented from using 
the bad blocks. Accordingly, PIP maintains a Bad Allocation Table. 
Whenever a user updates that table, PIP will set the appropriate bit 
in the Storage Allocation Table. The block is thus made unavailable. 
Refer to PIP manual (DEC-15-UPIPA-A-D) for more information. 
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CHAPTER 7 


WRITING NEW I/O DEVICE HANDLERS 

This chapter contains information essential for writing new I/O de¬ 
vice handlers to work in DOS, 

7,1 I/O DEVICE HANDLERS, AN INTRODUCTION 

All communications between user programs and I/O device handlers are 
® made via CAL instructions followed by an argument 'list. The CAL 

Handler in the Monitor (Figure 2=1) performs preliminary setups, 
checks the CAL calling sequence, and transfers control via a JMP* 
instruction to the entry point of the device handler. When the con¬ 
trol transfer occurs (see Figures 7-1 and 1-2), the AC contains the 
address of the CAL in bits 3 through 17 and bits 0, 1, and 2 indicate 
the status of the Link, Bank/Page mode, and Memory Protect, respect¬ 
ively, at the time of the CAL, Note that the contents of the AC at 
the time of the CAL is not preserved when control is returned to the 
user. 

On machines that have an API, the execution of a CAL instruction auto¬ 
matically raises the priority to the highest software level (level 4). 
Control passes to the handler while it is still at level 4, allowing 
the handler to complete its non-reentrant procedures before debreaking 
(DBK) from level 4, This permits the handler to receive reentrant 
calls from software levels higher than the priority of the program 
that contained this call. Device handlers which do not contain re¬ 
entrant procedures (including all handlers supplied with DOS) may avoid 
system failure caused by inadvertent reentries by remaining at level 
4 until control is returned to the user. 

If the non-reentrant method is used, the debreak and restore (DBR) 
instruction should be executed just prior to the JMP* which returns 
control to the user, allowing debreak from level 4 and restoring the 
conditions of the Link, Bank/Page mode, and Memory Protect, Any IOT’s 
issued at the CAL level (level 4 if API present, mainstream if no API) 
should be executed immediately before the 

DBR 
JMP * 
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Figure 7-1 

CAL Entry to Device Handler 


*For non-unibus devices both these branches would be replaced by a single initiate 
function routine. 















API 

ENTRY — via JMS* API Device Address 


PI 

ENTRY — via JMS 0 



Figure 7-2 

PI and API Entries to Device Handlers 1 


'’On a PI or API interrupt, the device handler is entered in Bank or Page mode, 
depending on the setting of bit 11 in .SCOM+4. If = 1, Bank mode; if = 0, Page mode. 
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exit sequence in order to ensure that the exit takes place before the 
interrupt from the issued IOT occurs. 

The CAL instruction must not be used at any level (API or PIC) that 
might interrupt a CAL, A CAL at such a level will destroy the content 
of location 00020 for the previous CAL. 


Care must also be taken when executing CALS at level 4 a For example, 
a routine that is CALed out of level 4 must know that if a debreak 
(DBR or DBK) is issued, control will return to the calling program 
(which had been at level 4) at a level lower than level 4. 

7.1.1 Setting Up the Skip Chain and API (Hardware) Channel Registers 

When the Monitor is loaded, the Program Interrupt (PI) Skip Chain and 
the Automatic Priority Interrupt (API) channels are set up to handle 
the TTY keyboard and printer and clock interrupts only. The Skip 
Chain contains the other skip IOT instructions, but indirect jumps to 
an error routine result if a skip occurs, as follows: 


SKPDTA 

SKP 

JMP* INTI 

SKPLPT 

SKP 

JMP* INT2 

SKPTTI 

SKP 

JMP TELINT 


/Skip if DECtape flag. 

/INTI contains error address. 

/Skip if line printer flag. 

/INT2 contains error address. 

/Skip if teleprinter flag. 

/To teleprinter interrupt handler. 


All unused API channels, memory protect, memory parity, and powerfail, 
also contain JMP's to the error address. 


When a device handler is called for the first time 
must call a Monitor routine (.SETUP) to set up its 
Chain, or its API channel, prior to performing any 


in a core load, it 
skip(s) in the Skip 
I/O functions. 
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The calling sequence is as follows.; 


CAL N 


16 

SKP IOT 
DEVINT 
(normal 


/N = API channel register 40 through 77 (see User * s 
Handbook Vol. 1 , for standard channel assign¬ 
ments) , 

/0 if device not connected to API. 

/.SETUP function code. 

/Skip IOT for this device. 

/Address of interrupt handler. 

return) 


7.1.2 Handling the Interrupt 


DEVINT exists in the device handler in the following format to allow 
for either API or PI interrupts. The following -is for UNIBUS devices 
only: 


ONLY1 


DEVPIC 


DEVINT 


IGNRPI 


COMMON 
DEVION 


LAC 

DAC 

DAC 

DAC 

JMP 

DAC 

LAC* 

DAC 

JMP 

JMP 

DAC 

LAC 

DAC 

JMP 


CAPI- 

ION 


(NOP 

DEVION 

DEVIOF 

IGNRPI 

COMMON 

DEVAC 

(0 

DEVOUT 

COMMON 

DEVPIC 

DEVAC 

DEVINT 

DEVOUT 

ONLY1 


/LEAVE PI ALONE. WHEN API IS RUNNING 

/THESE REGISTERS 

/ARE AVAILABLE 

/THIS IS ONCE ONLY CODE 

/SAVE AC 

/SAVE PC, LINK, ADDRESSING MODE AND 
/MEMORY PROTECT 

/PI ENTRY 

/API ENTRY; SAVE AC 

/SAVE PC, LINK, ADDRESSING MODE AND 
/API IS OPERATING, SO LEAVE PI ALONE. 
/PI INTERRUPTS ARE NOT POSSIBLE, BE¬ 
CAUSE .SETUP EFFECTIVELY NOP ! S PI 
/SKIPS. 

/CLEAR API LEVEL s -' DONE FLAG. 

/PI ALLOWS INTERRUPTS; API DOES A NOP. 


DEVIOF IOF 

LAC (TCB 

SIOA 

JMP .-1 

LIOR 

/DISMISS ROUTINE 


/API DOES NOP; PI TURNS 10 OFF TO ENSURE 
/NON-REENTRANCE AFTER ISSUING IOT 1 S. 

/GET ADDRESS OF TCB IN AC 
/PREVIOUS TCB ACCEPTED? 

/NO 

/YES. LOAD REGISTER IN INTERRUPT LINK 
/THIS CAUSES A BR7 (HIGHER LEVEL) 
/INTERRUPT ON THE PDP-11. 


LAC DEVAC 

DVSWCH ION 
DBR 

JMP* DEVOUT 


/RESTORE AC. 

/ION OR NOP. 

/DEBREAK AND RESTORE CONDITIONS 

/OF LINK, ADDRESSING MODE AND MEMORY 

/PROTECT. 


If the Index, Autoincrement, or EAE registers are used by the I/O de¬ 
vice handler, it is necessary to save and restore them. 



The following is for non-UNIBUS devices: 


0NLY1 

LAC 

(NOP 

/LEAVE PI ALONE. WHEN API IS RUNNING 


DAC 

DEVION 

/THESE REGISTERS 


DAC 

DEVIOF 

/ARE AVAILABLE 


DAC 

IGNRPI 

/THIS IS ONCE ONLY CODE 


JMP 

COMMON 


DEVPIC 

DAC 

DEVAC 

/SAVE AC 


LAC* 

(0 



DAC 

DEVOUT 

/SAVE PC, LINK, ADDRESSING MODE AND 
/MEMORY PROTECT 


JMP 

COMMON 


DEVINT 

JMP 

DEVPIC 

/PI ENTRY 


DAC 

DEVAC 

/API ENTRY; SAVE AC 


LAC 

DEVINT 



DAC 

DEVOUT 

/SAVE PC, LINK, ADDRESSING MODE AND 

IGNRPI 

JMP 

0NLY1 

/API IS OPERATING, SO LEAVE PI ALONE. 
/PI INTERRUPTS ARE NOT POSSIBLE, BE¬ 
CAUSE .SETUP EFFECTIVELY NOP 8 S PI 
/SKIPS. 

COMMON 

DEVCF 


/CLEAR DEVICE DONE FLAG. 

DEVION 

ION 


/PI ALLOWS INTERRUPTS; API DOES A NOP 


DEVIOF IOF 

DEVIOT 


/API DOES NOP; PI TURNS 10 OFF TO ENSURE 
/NON-REENTRANCE AFTER ISSUING IOT'S. 


/DISMISS ROUTINE 


DEVAC /RESTORE AC. 

/ION OR NOP. 

/DEBREAK AND RESTORE CONDITIONS 
DEVOUT /OF LINK, ADDRESSING MODE AND MEMORY 

/PROTECT. 


If the Index, Autoincrement, or EAE registers are used by the I/O de¬ 
vice handler, it is necessary to save and restore them. 


LAC 

DVSWCH ION 
DBR 
JMP* 
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„SETUP allows either API or PI, but not both for a single device. The 
System Generator Manual gives the method for incorporating new handlers 
and associated Skip Chain entries into the Monitor. 

7 9 2 API SOFTWARE LEVEL HANDLERS, AN INTRODUCTION 

The information presented in the following paragraphs assumes that the 
reader is familiar with the system input/output considerations described 
in the PDP-15 User's Handbook Vol. 1. 


7.2.1 Setting Up API Software Level Channel Registers 


When the Monitor is loaded, the API software-level channel registers 
(40 through 43) are initialized to 


JMS * 

. SCOM+12 

JMS * 

. SCOM+13 

JMS* 

.SCOM+14 

JMS* 

.SCOM+15 


/LEVEL 4 
/LEVEL 5 
/LEVEL 6 
/LEVEL 7 


where .SCOM is equal to absolute location 000100 and .SCOM+12 through 
.SCOM+15 (000112 through 000115) each contains the address of an error 
routine. 

Therefore, prior to requesting any interrupt at these software priority 
levels, the user must modify the contents of the .SCOM registers so 
that they point to the entry point of the user’s software level handlers. 


Example: 


. SCOM=10 0 

LAC (LV5INT /set level 5 entry. 

DAC* (.SCOM+13 


LV5INT exists in the user's area in the following format: 

LV5INT 0 /PC,LINK,BANK/PAGE MODE,MEM.PROT. 

DAC SAV4AC /SAVE AC 

/SAVE INDEX, AUTOINCREMENT AND EAE REGISTERS, IF LEVEL 5 
/ROUTINES USE THEM AND LOWER LEVEL ROUTINES ALSO USE THEM. 
/SAVE MQ AND STEP COUNTER, IF SYSTEM HAS EAE AND IT IS USED 
/AT DIFFERENT LEVELS. 


/RESTORE SAVED REGISTERS. 

DBR /DEBREAK FROM LEVEL 5 AND RESTORE 

JMP* LV5INT /L, BANK/PAGE MODE, MEM. PROT. 
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7.2.2 Queueing 


High priority/high data rate/short access routines cannot perform com¬ 
plex calculations based on unusual conditions without holding off 
further data input. To perform the calculations, the high priority 
program segment must initiate a lower priority (interruptable) segment 
to perform the calculations. Since many data handling routines would 
generally be requesting calculations, there will exist a queue of cal— 
culation jobs waiting to run at the software level. Each data handling 
routine must add its job request to the appropriate queue (taking care 
to raise the API priority level as high as the highest level that 
manipulates the queue before adding the request) and issue an interrupt 
request (ISA) at the corresponding software priority level. The general 
flow chart. Figure 7-3,, depicts the structure of a software handler 
involved with queued requests. 

Care must be taken about which routines are called, when a software 
level request is honored; that is, if a called routine is "open" 

(started but not completed) at a lower level, it must be reentrant, or 
errors will results. 


NOTE 

The DOS hardware I/O device handlers do not 
contain reentrant procedures and must not be re¬ 
entered from higher levels. 

Resident handlers for Power Fail, Memory Parity, 
nonexistent memory violation, and Memory Protect 

violation have been incorporated into the system 

and effect an IOPS error message if the condition 
is detected. The user can, via a .SETUP, tie his 
own handler to these skip IOT or API channel regis¬ 
ters. 
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7.3 WRITING SPECIAL I/O DEVICE HANDLERS 


This section contains information prepared specifically to aid those 
users who plan to write their own special I/O device handlers for DOS. 

DOS is designed to enable users to incorporate their own device hand¬ 
lers. Precautions should be taken when writing the handler however, 
to ensure compatibility with the Monitor. 

Here is a summary of handler operation. The handler is entered via a 
JMP* from the Monitor as a result of a CAL instruction. The contents 
of the AC contain the address of the CAL in bits 3 through 17. Bit 0 
contains the Link, bit 1 contains the Bank/Page Mode status, and bit 2 
contains the Memory Protect status. The previous contents of the AC 
and Link are lost. 

In order to show the steps required in writing an I/O device handler, 
a complete handler (Example B) was developed with the aid of a skeleton 
handler (Example A). In addition, Appendices A and B are complete 
flowcharts of the DTA and the A version of the disk handlers. The 
skeleton handler is a non-reentrant type (discussed briefly at the 
beginning of this chapter) and uses the Debreak and Restore Instruction 
(DBR) to leave the handler at software priority level 4 or at a hardware 
level for interrupt servicing (if API), and restore the status of the 
Link, Bank/Page Mode, and Memory Protect. Example A is referenced by 
part numbers to illustrate the development of Example B, a finished 
Analog to Digital Converter (ADC) I/O Handler. The ADC handler shown 
in Example B was v/ritten for the Type AF01B Analog to Digital Converter. 
This handler is used to read data from the ADC and store it in the 
user's I/O buffer. 

The reader, while looking at the skeleton of a specialized handler 
as shown in Example A, should make the following decisions about his 
own handler. (The decisions made in this case are in reference to 
developing the ADC handler): 

a ° Services tha t are required of the handler (flags, 
receiving or sending of data, etc.) - By'looking 
at the ADC IOT’s shown in the Reference Manual, it 
can be seen that there are three IOT instructions 
to be implemented. These instructions are: Skip 
if Converter Flag Set, Select and Convert, and Read 
Converter Buffer. 


7- 1C 



The only service the ADC handler performs is that of 
receiving data and storing'it in user specified areas. 
This handler will have a standard 256-word buffer. 

Data Modes used (for example, IOPS ASCII, etc.) - 
Since there is only one format of input from the 
Type AF01B ADC, mode specification is unnecessary in 
Example C. 

Which I/O macros are needed for the handler's specific 
use; that is, .INIT, .CLOSE, .READ, etc. For an ADC, 
the user would be concerned with four of the macros. 

(1) .INIT would be used to set up the associ¬ 
ated API channel register or the interrupt 
skip IOT sequence in the Program Interrupt 
Skip Chain. This is done by a CAL ■ (N) as 
shown in Part III of Example A, where (N) 
is the channel address. 


(2) .READ is used to transfer data from the ADC. 

When the .READ macro is issued, the ADC 
handler will initiate reading of the speci¬ 
fied number of data words and then return 
control to the user. The analog input data 
received is in its raw form. It is up to 
the programmer to convert the data to a 
usable format. 

(3) .WAIT detects the availability of the user's 
buffer area and ensures that the I/O trans¬ 
fer is completed. It would be used to ensure 
a complete transfer before processing the re¬ 
quested data. 

(4) .WAITR detects the availability of the user's 
buffer area as in (3) above. If the buffer 
is not available, control is returned to a 
user specified address, which allows other 
processing to continue. 

Implementation of the API or PIC interrupt service routine 
Example A shows an API or PIC interrupt service routine 
that handles interrupts, processes the data and initi¬ 
ates new data requests to fully satisfy the .READ macro 
request. Note that the routines in Example A will oper¬ 
ate with or without API. Example B uses the routines 
exactly as they are shown in Example A. 

During the actual writing of Example B, consideration was 
given to the implementation of the I/O macros in the new 
handler in one of the following ways: 

(1) Execute the function in a manner appropriate 

to the given device as discussed in(c). .INIT, 

.READ, .WAIT, and .WAITR were implemented into 
the ADC handler (Example B) under the subroutine 
names ADINIT, ADREAD, ADWAIT (.WAIT and .WAITR). 

Wait for completion of previous I/O. (Examole B 
shows the setting of the ADUND switch in the ADREAD 
subroutine to indicate I/O underway.) 




(2) Ignore the function if meaningless to the device. 
See Example B (.FSTAT results in JMP ADIGN2) in 
the dispatch table DSPCH. For ignored macros, 
the return address must be incremented in some 
cases, depending upon the number of arguments 
following the CAL (see Chapter 3). 

(3) Issue an error message in the case where it is 
not possible to perform the I/O function - (An 
example would be trying to execute a .ENTER on 
the paper tape reader.) In Example B, the handler 
jumps to DVERR6 which returns to the Monitor with 
a standard error code in the AC. 


e ” Special considerations for UNIBUS device hand lers 

When new handlers are written for devices on the UNIBUS 
in a UC15 system (RK based or RF/RP based UC15 option) 
the following has to be considered. 

Since communication between the device handler on the 
PDP-15 and the driver task running under PIREX on the 
PDP-11 is through Task Control Blocks (TCB), space in 
the Common Memory (memory that can be addressed by the 
PDP-15 and the PDP-11) must be provided. The system 
as supplied by DEC has space reserved in the Resident 
Monitor for 3 user defined devices/programs/tasks, 

(refer to Section 2.9 for more information). This TCB 
must be properly setup (refer to the UC15 Software 
Manual , DEC-15-XUCMA-A-D for more information) before 
the handler calls PIREX to initiate the operation. 

Driver tasks (TTT) 1 running under PIREX report errors 

by setting the appropriate code (XX) in the device 

error status table in PIREX (refer to UC15 Software Manual , 

DEC-15-XUCMA-A-D for more information). DOS-15 

system prints out this error message, which appears 

as follows: 

XOPSUC TTT XX 

Users have to decipher this message. An example of this is, 

IOPSUC LPU 4 

which reports that the LP11/LS11 line printer is not 
ready® There is no error message type out from the 
handler. This method of error handling is incorporated 
to permit error report during operation of these 
devices/tasks etc., under PIREX when their corresponding 
handlers are not present in core on the PDP-15 (e.g., 
during Spooling). 


J Each task running under PIREX has a 3 character code assigned to 
it which is present in the PIREX error table at assembly time. 


7-12 



After the handler has been written and assembled, the Monitor must 
then be modified to recognize the new handler. This is accomplished 
by the use of the System Generator Program (DOSGEN) described in the 
DEC-15-USGNA-A-D manual. 

When the system generation is complete, the PIP program (refer to 
DE015-UPIPA-A-D) must be used to add the new handler to the IOS UFD. 
At this time, the user is ready to use his specialized device handler 
in the DOS-15 system. 

7.3.1 Discussion of Example A by Parts 


Part 1 Stores CAL pointer and argument pointer, and 

picks up function code from argument string. 

Part 2 By getting proper function code in Part 1 and 

adding a JMP DSPCH, the CAL function is dis¬ 
patched to the proper routine. 

Part 3 This is the .SETUP CAL used to set up the PI 

skip chain or the API channel register. 

Part 4 Shows the API and PI handlers. It is suggested 

these be used as shown. 

Part 5 This area reserved for processing interrupt and 

performing any additional I/O. 

Part 6 Interrupt dismiss routine. 

Part 7 Increments argument pointer in bypassing argu¬ 

ments of ignored macro CAL’s. 




7-3.2 Example A, Skeleton I/O Device Handler 


/C^L ENTRY ROUTINE 


3 mED-3 

o Glopl 

OE v 9 

n E V „ 

0 A C 

DVCALP 


0 AC 

DVARGP 


IS? 

D V A R G P 


L AC® 

DVARGP 


and 

( 77777 


IS? 

DVARGP 


TAD 

(JMP Q5PCW 


nAc 

D S P C h 

DSpch 

xx 



JM P 

0 V I N I T 


JMP 

DVFSAT 


JMP 

D V S E E K 


JMP 

D V L N T R 


JMP 

D V C L E R 


JMP 

DVCLOS 


jMP 

0 V M T A P 


jMP 

1 V READ 


jMP 

U V *s R T E 


JMP 

0 V W A I T 


jMP 

D V T R A 


/ILLEGAL F sj m C T i 0 M S p- ABOVE 
/ J H p D V E R W 6 


/ M U S T BE QF FOWM A A A s 

/« M E n (monitor error diagnostic) 

/SAVE CAL pointer 
/AND ARGUMENT p n t m t er 
/POINTS TQ FUNCTTOK~' , OQE 
/GET COOL 

/REMOVE UNIT NO ?F APPLICABLE 
/PQ I Y?S TO CaL«^2 

/ n IS P A T C u WITH 
/“ODIFIEO JUMP 
/1 » e I N I T 

/? § .ESTAYs § DlFTE s 9 R£NAM 

/3 S .SEEK 

/4 = .enter 
s .Clear 
/6 * .close 

/? s ,MTAPE 
/1Z a .READ 
/II s ,WRITE 
/ 1 2 S g Ai 4 I T 
/13 s 9 TRAN 


table cmE” ass 


/FUNCTION COHE ERROR 
0 VE R R 6 lA* 6 

jMP® (,«EH*1 

/data mode error 

0 V E R R 7 law 7 

JMP& ( ,M E D + 1 

/DFVICE NOT READY 

'' V E P P 4 |_Ar (RFTuR.N 


H A C * (,Mfj 

t_ A C (4 

jmp* ( 8 ^En<*-1 

/I/O UNDERWAv lCOR 

T VBUS Y OBR 

j m p « f) V C A L p 

/normal return FROM cal 
"VCK oBR 

JMP* D V A PGP 


/ERROR CODE 6 
/TO mOVJTOR 


/PRROP CODE 7 
/TQ M O fi f TOR 


/RETURN (ADDRESS IN mAMDLE h > 
/TO RETURN Tr WWfM NOT READY 
/coN!i t jo n has been removed 


/ERROR CODE 4 

/TO monitor 


/BREAK RRQM LEV£| 4 

/1,0OR CAL 


/B RE A K FROM L EVL F 4 
/RETURN AFTER C A i ANC 
/ARGUMENT STRING 


/THE D V ImIT ROUTINE must INClUDE 
/A a SETUP CALLING SEQUENCE F 0 R 


7-14 



/N s API CHANNEL REGISTER 
/(4? -77), N s 0 IF NOT CQ^NrcTEn 
/TO API 

7 I O p S F tJNiCTlO.M CpDE 
/SKIP 10T TO TEST Thf FLAG 
/ADDRESS OF INTERRUPT 
/HANDLER (PI OR API) 

SUBROUTINES 

/interrupt handler for api or pi 


ONLVl 

L AC 

( NOP 

V* r i 


DAC 

DEV I ON 



0 A C 

OEV IGF 



DAC 

UVSLCH 



DAC 

IGNRP I 



jMP 

COMMON 


L i V i lU 

DAC 

DEVAC 

/SAVE AC 


lac® 

( T 

/SAVEfPC, LINK, RANK/PAGE MODE 


DAC 

i»Y u u i 

/AND mFmORY PROTECT 


jMP 

COMMON 


1 V i .< Y 

JMP 

PE VP I C 

/PI entry 


DAC 

DEVAC 

/api entry? save ac 


lac 

D E V I ,\ T 

/saves pc, link, bamk/page mode 


DAC 

DEVOUT 

/nEmqRY protect 

IGNRP 1 

JMP 

OULY1 

/LFAVE pi alone 

COMMON 

QEVCF 


/enable pi OR NOP 

oEVION 

I ON 


/enable pi or mop 

/this a I 

thf 

AREA DEVOTED 

To PROCESSING INTERRUPT AMD 

/PERFORMING AMY ADDITIONAL 

I/O DESIRFC, 

DEVI OF 

I of 


/DISABLE PI pR NoP 


oEv i nr 


/niMISSAL before INTERRUPT 


/frdh this loT occurs 

route 

/RESTORE AC 
/ION C B m'QP 
/DEPPE A « A NU REStQRF 
/link, -jank/page m nnr , memory 

/PROTECT 

/IF THE HANDIER USES THE A U T 0 I N C R E M E VT , jkjUEX 
/OR E A E REGISTERS, THEIR CONTENTS 

/should g e Saved amd restored* functions 

/POSSIBLY IGNORED SHOULD CONTAIN 
/PROPER INDEXING TO BYPASS 

/C4L argument string 
/ 

/CODE To Bypass IGNORED FUNCTIONS 
/ 


/Interrupt handler dismiss 

^VOISM L A C DEVAC 

DVSWCH IQM 
DBR 

J MP » DEVOUT 


/each flag connected to api 

/ANO/OP PI A(AT SGEN TIME) 8 

/the setup calling sequence is? 

DVIN1T CAL N 



C I. V i . I i 


/THIS SPACE may be USED for I/O 


OVIGN2 !s i dvargp /BYPASS file POINTER 

J M P Q V C K 
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Example B , Special Device Handler for AF01B A/D Converter 
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/ILLEGAL FUNCT!0>S I v AROvt TABLF CO 
/ JMP AD£RP6 

» £ Jt C T 



/FUNCTION CODE ERROR 
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CHAPTER 8 


BOSS-15 


BOSS enables DOS users with a card reader and a line printer to run 
jobs sequentially, with a minimum of operator intervention. BOSS sup¬ 
ports a subset of the DOS system programs, and adds a line editor, its 
own resident and nonresident routines (called Resident BOSS and Non¬ 
resident BOSS), and the Procedure Files. Paragraph 8.1 describes Pro¬ 
cedure Files. Figure 8-1 shows which monitor supports each system 
program. 

The DOS programs run by BOSS are identical to those run by DOS. Ex¬ 
ceptions are the Resident and Nonresident Monitors, which are ex¬ 
plained later. BOSS expands the information on Control Cards into 
a series of commands in the format expected by the DOS system pro¬ 
grams, Nonresident BOSS does this command expansion, and stores the 
expanded commands in a disk file, the Run Time File (RTF). Since DOS 
programs expect to communicate with an operator at a teleprinter, BOSS 
feeds the expanded commands to the programs via .DAT slots assigned 
to TTA. In BOSS mode, therefore, BOSS attaches .DAT-2 to the Run Time 
File, and directs most teleprinter output to the Line Printer. Pro¬ 
grams can force I/O to the teleprinter by setting bit 4 in .SCOM+52, 
and proceding with macros directed to TTA. 

Whenever bit 0 of .SCOM+52 is set, the System Loader Interface attaches 
the Resident BOSS code to the Resident Monitor. The main purposes 
of Resident BOSS are to (1) ensure that BOSS will retain control of 
the teleprinter, (2) feed commands to programs via the Run Time File, 

(3) properly route internal Monitor commands, such as .EXIT, .GET and 
.PUT, and (4) direct teleprinter output to the Line Printer. Figure 
8-2 illustrates the connections between the DOS Resident Monitor and 
the BOSS Resident Monitor that accomplish these changes. Figure 8-3, 
the flowchart for Resident BOSS, further describes Resident BOSS. 

Resident BOSS communicates with Nonresident BOSS by TRANing informa¬ 
tion to and from the first block of Nonresident BOSS. Nonresident 
BOSS gains control on all error conditions, such as IOPS, operator 
abort, Time Estimate exceeded, and after a B0SS15 command. Figure 8-4 
is a flowchart of Nonresident BOSS. 





Figure 8-1, BOSS/DOS Intersection 







RESIDENT B0SS15 INTERFACE TO RESIDENT MONITOR 
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- PROGRAM CONTROL 
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*IF QDUMP WAS SPECIFIED THEN THE DUMP NOTE: SEE RESIDENT BOSS FLOW CHARTS 
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Figure 8-2 

Connections Between DOS Resident 
Monitor and BOSS Resident Monitor 
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Figure 8-3 (Cont.) 
Resident BOSS-15 


8-5 
















• EXIT TIME OUT Operator .PUT AND .GET 

Processing Processing Abort +T Processing 



Points within the Resident Monitor which transfer control to Resident BOSS-15 


Figure 8-3 (Cont.) 
RESIDENT BOSS-15 













Start Address 420 



Figure 8-4 
Nonresident BOSS 


8-7 










< /was s s N 
there an 
JOPS er- 


Set bit 5 in Job 
Status Word 



Print on Line Printer, 
"TERMINAL ERROR. 




Print on Line Printer, 
"LOAD ERROR. 


Set bit 16 in JOB 
Status Word 


Set bit 6 in Job Status Word 



Set bit 3 in Job Status Word 


Time 

estimate 
exceeded 


Print on Line Printer, "TIME 
ESTIMATE EXCEEDED" 


■Operatoi 
\abort* 


Set bit 7 in Job Status Word 
Print on LP, "OPERATOR ABORT" 


Figure 8-4 (Cont.) 
Nonresident BOSS 





















$CRT $ADD 



(Other) 


/ SUBSTT 



Figure 8-4 (Cont.) 
Nonresident BOSS 






MMa 


Set up to get character from card: 
Skip over "$" and pack character in 
CARDP 



Figure 8-4 (Cont.) 
Nonresident BOSS 
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8.1 PROCEDURE FILES 


To each BOSS command there corresnondc; , 

unesponas a disk-resident ASCII file 

Whe^nos Pr ° CedUre Flle ‘ The Proce<i “ re Pile contains DOS commands. 
When DOS executes the commands in the Procedure File, it carries out 

e function specified by the BOSS control card. The DOS commands 
m the Procedure Files contain fields (for instance, a file name) 
that Nonresident BOSS fills in with text strings from the control 
card. These fields are called, "Variable Fields". Before executing 
the DOS commands contained in the Procedure File, all the variable 
fields have to be resolved. This process is very similar to 
a macro expansion, where (1) DOS is the assembly language, (2) the 
BOSS command name is the macro name, (3) the contents of the BOSS 
control card are the macro arguments, and (4) the Procedure File is 
the macro definition. The expanded DOS commands are put in a Disk 
File, called the "Run Time File (RTF)". The RTF can contain the ex¬ 
pansion of one or more Procedure Files, up to 777 g IOPS ASCII records 

BOSS expands Procedure Files strictly on a text string, character 
basis. It has no knowledge of the intrinsic function of each BOSS 
control card, except for SJOB, $END, $CRT, and $ADD (SEND, SORT, ? ADD 

have no Procedure Files, Appendix c contains a listing of all standar 
Procedure Files. 

8.1.1 Procedure File Format 

in order to ensure successful expansion, all Procedure Files must fol¬ 
low a strict format. The first record of the Procedure File must be 
a control record, with parameter information. The first record may 
also contain comments, because BOSS interprets only pertinent informa¬ 
tion, and ignores the rest. The numbers 0, 1, 2, 3, and 4 specify 
different options. All other characters are ignored. The option 
digits can ^appear in any order, and anywhere on the record. The op- 
tion specified by each number is given below: 


0 Expanded Substitution (default, if "3" not aiven 
explicitly) 

This option specifies that the Procedure File is to be 

expanded according to the normal rules of substitution 
which are given below. tu tion, 
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1 - Open Ended File (default, if "2" not given 

explicitly) 

This option instructs the Nonresident BOSS Monitor 
to leave the RTF open after expanding the current 
Procedure File. BOSS then searches for the next 
control card. 

2 - Closed End File 

This option instructs Non-resident BOSS to close 
the RTF after expanding the current Procedure File, 
and to execute the DOS commands in the RTF. Pro¬ 
cedure Files corresponding to commands that may 
possibly be followed by "Data Cards" should be 
of Type 2. 

3 - Direct Substitution 

This option indicates the BOSS should not expand 
the Procedure File according to normal rules. 

Refer to paragraph 8.1.2 for information on 
Direct Substitution. 

4 - Test Mode 

This option indicates that BOSS should echo the 
Procedure File expansion on the Line Printer. 

This allows a check on the Procedure File. 

The following combinations are illegal: 

0 and 3 
1 and 2 


If BOSS finds an illegal option combination, it will print, 

ILLEGAL PROC FILE 

and search for the next control card. 

BOSS uses all other records in the Procedure File as macro definition 
records. Records after the first one are all Macro Definition Records. 
For each such record, a record will be written in the RTF. Each Macro 
Definition Record has the same format. Two types of fields are used: 
K-fields and V-fields. K-fields specify constant character strings 
that will be written into the RTF exactly as they appear in the Pro¬ 
cedure File. V-fields specify variable character strings to be sub¬ 
stituted from specified strings on the Control Cards. Each Macro 
Definition Line of a Procedure File can contain any number of K- and 
V-fields, in any combination. v-fields are delimited by 0-siqns. 
K-fields are delimited by adjacent V—fields, or the end or beginnina 



of the record. Since there are only two types of fields, only one 
need have delimiters. Two adjacent V-fields, however, require two 
adjacent @-signs. 

K-fields 

K-fields may be any string of legal IOPS ASCII characters, except the 
@-sign. 


V-fields 

A V—field has the following format*: 


v 


/A0n\ 

J U0n V f r/V-fieldV . a 
M Dnn V.K-field/ ^ @ 




V 


The two @-signs delimit the field. The first part of the field (A, 
D, u or 0) is a card-position identifier, and must be present. It 
identifies the position on the current Control Card of the character 
string to be substituted in the RTF. The legal combinations are: 


A00,A01, . . . . A09 
U00 , U01 ,... .U09 
D00 ,D01,- D09,D10, ...D17 

0 


With the exception of D10 through D17, each of the above position 

identifiers corresponds to a unique character staring- o£ the Control 
Card, according to the following scheme: 

$CMD ;0 A00 : D00(U00) ;A01:D01(U01);... . ;A09:D09(U09 ) 

The D10...D17 position identifiers do not correspond to character 
strings found on the Control Card, but rather to character strings 
defined by BOSS. Thus, 

D10 -- Unused 

Dll - .SIXBT representation of 
('DK' or 'DP' or 'RK') 

D12 - Current Logged in UIC 

D13 - .SIXBT representation of 

D14 - .SIXBT representation of 

D15 - Unused 

D16 - Unused 

D17 - Unused 


the System Device Code 

Carriage RETURN 
ALT MODE 


* Standards for this format description are identical to those soeci- 
ried m Chanter 5 of the DOS-15 User's Manual, DEC“15“0DUMA-B-b„ 
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The parentheses in a V-field must be present. They are used to speci¬ 
fy a default string. The default string is used in case the string 
on the Control Card specified by the position identifier is null. A 
set of parentheses must be included, even if the default string is 

null. The default string itself can be a variable, resulting in nested 

17 

variables. Nesting has a theoretical limit of 2 variable fields. 

8.1.2 Direct Substitution 

When processing a Direct Substitution Procedure File, BOSS places the 
fields on the Control Card into the RTF just as they stand with only 
leading spaces ignored. That is, BOSS does not necessarily expect to 
find file names, and so on, as with normal substitution. Fields on 
the Control Cards are separated by semi-colons (;), and are processed, 
in a serial manner. The ampersand (&) is used for a special purpose. 

It causes the current record being composed for the RTF to be termin¬ 
ated with a Carriage RETURN, and written out, and a new record started. 
This is so that the limit of seventy-five characters per line will not 
be exceeded. 

There are only two legal field types within the Procedure File. They 
are as follows: 

1. A00 through A99 

2. D10 through D17 (System Defined) 

In making up Direct Substitution Procedure Files, the following rules 
must be followed: 

1. The first line must contain a three (3). This declares 
the file to be direct substitution. 

2. The "A" fields must appear in sequential order, starting 
at A00. Each "A" field can be used only once within the 
Procedure File. 

3. The "D" fields can only be "Dlj?" through "D17". They 
can be used any number of times, in any order. 

4. Variable expressions must follow the standard V-field 
format, as in expanded substitution. 

8.1.3 Example of Procedure File 

The following example shows a typical Direct Substitution Procedure 
File, the Control Cards used to call it, and the resulting lines 
produced in the Run Time File. 
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Procedure File 1 ™ Map PRC 


3 PROCEDURE FILE TO RUN CHAIN WITH NO OVERLAYS 
CHAIN 

@A00(TMPXCT)@@D14()@ 

@A01(SZ)@@D14()@ 

@A02 (FILTMP)@@D14() @ 

@D14 ()@ 


Control Cards as They Appear 


$MAP TESTl; S Z ,VTC/ABC,DEF,NAM1,&NAM2,; 
$*01 NAM3,NAM4,NAM5/;TESTl,SUBl,SUB2, & ; 
$*02 SUB3,SUB4,SUB5 


Run Time File Lines 


CHAIN ) 

TESTl (ALT MODE) 

S Z,VTC/ABC,DEF,NAM1,) 

NAM2,NAM3,NAM4,NAM5/ (ALT MODE) 
TESTl, SUBl, SUB2,) 

SUB3,SUB4,SUB5 (ALT MODE) 

(ALT MODE) 


Note: Dl4-Altmode, <ALTMODE> is an Altmode, and <CR> is a 

Carriage Return. 

8.2 BOSS-15 ACCOUNTING 

BOSS has a very simple accounting mechanism. It keeps an account 
record for each job in a random access file in the CTP UFD. Hence, 
tne j-ile is protected, and can only be accessed after successful ex¬ 
ecution of a $MIC command. 

The name of the accounting file is ACCNTG nnn. (The first has an ex¬ 
tension of 001.) Each file is ten physical blocks long, and contains 
enough information for 310 jobs, thirty-one per physical block. When 
BOSS fills up one file, it increments the extension, and starts a new 
one. Every time a job ends, BOSS checks whether ACCNTG 001 exists. 

If it does not, BOSS creates one. If it does, BOSS checks whether 

ir is full. If not f ull, BOSS makes a new entry; if full, BOSS 
^Direct Substitution File 
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searches for the first unused extension number. If all extension num¬ 
bers have been used (up to 999) BOSS prints this message to the opera¬ 
tor on the teleprinter: 

MAX NUMBER OF ACCOUNTING FILES REACHED 
PLEASE PROCESS AND DELETE THEM 

Every time the system manager processes an accounting file, he should 
delete the file.BOlO 


For each completed job, BOSS writes out an eight-word record to the 
accounting file. The recorcts have the following format: 


Word # 


Content 


1^ f Job I.D. , 

2 V 1 in 

3 J . SIXBT 

4 Date, packed mmddyy 

5 Start Time, in hhmmss 

6 End Time, in hhmmss 

7 Run Time, in hhmmss 

8 Terminal Job Status Word 


A word whose contents equal 777777g immediately follows the last job 
accounting record in each physical block of the accounting file. 


8.3 3.PRE 


Figure 8-5 is a flowchart of B.PRE, the BOSS ^ine Editor. 





Figure 8-5 
B.PRE 
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APPENDIX A 


DECTAPE "A" HANDLER (DTA 8 ) 

The following flow charts describe the operations of the DECtape 
""A" Handler. 
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INTERRUPT SECTION 



A-9 





























APPENDIX B 


DISK "A" HANDLERS 

The following flow charts describe the operation of the Disk "A" 
Handlers. 
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1. Save pointer to buffer, and zero entire buffer 

2, Complete the Busy Table entry 


-- 

--—- k ______________ 

1» Get UIC from the Busy Table entry 
2. Bring in the Current Set from buffer 
3« Set up pointers to; User's Directory Entry, tem¬ 
porary block list, Data Block Words 0,1,2,3,376 & 
377 
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Depending on the location of the desired blocks rela¬ 
tive to the RIB block in core, read in the next or 
preceding RIB block 
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I 


1. Set backward and forward links to -1 
2„ Turn on bits that correspond to MFD 
block and first submap block 


./MoreX. 

than 

.four plat- 















Next Page 


B-15 













Y 


N 



Next Page 







B —16 








B-17 









B-18 












Save pointer to "next" record 



fRgad in previous blocKj 


CBLOK 


Position record pointer toj 
top of the buffer | 



Use this record's word pair 
count to point to the next 
record __ 










Make Word Pair Count 
negative 

Zero checksum word in 
record to be read 
Clear line error flag 


r PWORDS' 
Pass record 
,to user t 



Set pointers for a skip over 
the next record 
2. Set "Short Line " Flag 
3» Set return in PWORDS to go 
to ENDINl 


PWORDS 
Skip rest 
of line 



B-20 













SETUP 


READ-WRITE Common Setup Routine 
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APPENDIX C 


PROCEDURE FILE 


ASG 

1 ASSIGN DEV TCP UIC TO ,OAT 
A < « U ?■ 2 ( ® D 12 ( ) @ ) 9 > <? A ?£()<? 

ASM 


? MACRO and line EDITOR 

A @D00 ( @oll ( ) @ ) 9 <®U£0<@(U2( )«>£> -14 /@f}Z3 ( @>r H ( j 9 ) <a <(*ij0;5 ( @n j 2 ( ) ® ) @> 

q a PRE 

@A00(FILTMP)@ 

@A01(@A00(FILTMP) @) @ 

A @000 i ®Dll c > » ) p <»U£?7 , <@D12( )*>»> -il/^Del ( 0C-11 { ) @ ) 9 <@U^1 <@01 2 ( ) 9 ) @> -1-* 
A @032 ( @011 { ) @ ) @ <«u?2 ( @Di2 ( ) ® ) @> -14/®DS5 ( @011 ( 5 @ ) @ <@lj05 '@D1.2( >@)*> -13 
A ®DP4 <lp1* <@U£'4(@012( )»)@> -12 
“ACRO 

( B.L ) @4-®A?0 ( F T LTMP ) ®@D14 ( ) 9 


BNK 

2 BANK MODE OPERAT ION-ON 
BANK ON 


BUF 

i uui l» r. v.>r .. ur r’L.-.;* 

PUFFS @A7?{>@ 

CHN 


1 SPECIFY 7 9 TRACK MAGTAPE 

0 @ a 3 0 ( > ? 


CMP 


1 SOURCE COMPARE 

A ® 0 C 0 ( @ r> 11 ( ) @ ) ® <-*«jO0 (®0l2( )@)®> -15/®021 <®Oll c )®)@ < @012 ( @ > -1.4 

s r c c;] m. 

.« n ( ) *« *■ 0 a 0 0 ( ) ' / @ A 01 ( ) @ ® 01 4 ( ) <3 


DIR 


i list Direct0by 
p I p 

! LP^^A^f ( ®m 1 ( > ^ <@US?$? < @Dl2 ( ) @ ) @>"9014 ( ) @ 


C-l 




DLG 


? LOGOUT JIC 
LOGOUT 

DMP 

01 DUMP UTILITY - EXPANDED SUB FILE 

DUMP^ eC?>nllC )&)9 )pl ^> -14/@321 (LP 5® <«»UPt(t*D12 -\2 

®A0? ( ALL ) @>@01 4 { )o 


DOS 

1 s 3 « G F N r « a l P»C P ILL F C R GIVING C 0 M m A N 0 S T H i fv G S 

n??(^ni4() >') p. 


FIL 

2 create: a Ff^r from carqs/eoitor 

A «OG0 ( *011 ( ) » ) « < «HJC0 ($012 < )®)@> -14 
a * o l (* o 11 () ®) @ <■* u r i (s> n 1 2 ();»j @ > «i5 
" # pwr 

® A o!?. ( F I L T v P ) * 

A 0 1 ( !* A P ^ { F 11 T M P ) « ) sp 


FOR 

2 FORTR A ,! 1 V A -■ D I. I \t FC I TOR 

a <-’■ iVF(«-H2( ) *)*> (@-,11 ( )9)» < @» L i 0 1 ( sn] 2 t ) o , *> _«s 

« , P R F 

@A00 (FILTMP) @ 
p A ■"* 1 (WAS * ( F I L TmP) « ) 

A «r!?(®nii()P)« <■'•!;.••? (?L12< )®)®> -J.1/C')/1 (6*011 {>*>» <t>uJ5i(*ni?nP)«> < 

A ■»rs-’? ( LP> * ( ’•01 2 ( ) » ) >?> “12 

F 4 

’ 0 ( f< I. > !* *• ® A c 0 ( F I L T M 0 ) & 5® 0 1 4 ( ) *S> 


JOB 

0 p 'TAPT -t-. JCP 
Log jcf -■? a r , j? ( ) « p f r; j @n 14 ( > $> 

T 

L H G I ' « A ■* 2 ( S'* P ) i® 

4 *'C' ?, 3, 4 ,7,IF,11,12 p 15, 14 , ib >1 * 917 ,?^/«01l ( )@ 1 

PIP 

^ C1.1 ( 5 ® < (SCR) >@Dl4 ( ) @ 

*» a 0 ;< () & 

P" C* P (5(5 ^ ^ £ f'i p £* ^ 

T I HE ST s,Ui(i!?:'-' 
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KEP 


1 RETAIL DEVICE A5S IGNi^f iTS 
<IZP @A0D()@ 


LCM 

13 SUPFurMF^r to L IB PRC-UPDaTe ,L IRR 
®A00(CLOSE«Dl3( PA0l(®Oi3()@>)® @A0?(>« 


LIB 


1 

A $)D 00 ( »Dil ( ) 9 ) ® <:?U 00 (@D 12 ( )@ 1 @> -H 

a @001 (Qn? 1 ^ (* nil () ®@ <@u0i (@u ;''0 i @012 ( ) 9 ) 9 ) @> - 1 & 

A *O02(@Ollt)@)@ < ® U 0 2 ( @ 012 ( ) @ ) @ > 

4 @ 0 7 3 < L p ) @ < !H' 0 3 O* D12 < ) @ ) «> “12 
UPDATE. 

»0 ( LUS ) ' ( , L I BP > s»@D14 < I 9 


LNK 

13 DIRECT S'J- FILE - BUILDS L Inks FOR FYECJTF FIlE-USE WITB OVL f'Er 
*A00(@014( ) ®)@®Dl4 ( ) 9 


LOG 

? LOGIN lie 

logI st ®AD"<srfi)p 

LST 

2 LIST c0NTE" ! TS OF FILE ON 1 L IL PRINTER 
PIP 

T L. p *- © c f» ;• <•?•[) 3 t ().?•) @> <?U??(S>0l2( )®)?> © A v9 ( F I !.. T ,M P ) © C A ) © Q 1 4 < ) © 


MAP 


1 J 3 DIRECT Sir F ILF FOP CPA Jf- OPTION a NlJ RES CC0f -'Hi y 
ORAL. 1 

®A00(TMPYCT)®@D14? ) @ 

@ 

SAD?(FIL T M P)»@ni4 ( ) 9 

© 014 ( ) p 


MIC 


p [_ oo ? \ *■ I r ■ ■ t '■ 

M I 01 ~ G @ A 0 * M © 





MNT 


1 M n U h T T A P F a 0 NJ j p I V E 4 

LOGw Mntj'iT ®n ( n ) «-TAPE # S»A80( ) e 0" DR I V'£s ( )p - kR I TE @> A ? 


MSG 

13 MESSAGE Tp OPERATOR -DIRECT SUB EIlE 
LOG «A 0 0( ) « 


MSW 


1.3 M E s S A G E T 0 OPERATOR W/W A ! T-0 I RF C T SUB 
1 0 r, w $ a ;* r { i «* 


NDR 


1 CREATE v Z W DIR f' r T n k V 
dip 

® A^-P ( C»Dll ( ) @> j C* < ®U00 ( Ppl2 ( > 9 ) !3>(*D14 ( ) a 


OVL 

13 DIRECT ?UR FILL - USE F C R 9 L I L 0 I M 0 OVERLAYS ( C^A I i\, ) 

i. H A I vj “ 

A 0 U ( T 0 P Y C T ) P D 14 { ) 3i 
*A M (Sf ) )@ 

^ A T 2 ( F I ( r m p ) * gp n 14 ( 5 •» 


PAG 


? p A G E m p n r - p. p r< A T ?f m n s 
r, AGE OP 


PRT 


i SPECIFY PROTECTION CODE 

p «A/Z(2) 


QDP 


iRr 


1 1 ' A L E R R 0 P S - >\j C A R f. 1! 


XCT 


r> F \ e r i r r 

9 0 1 ? { ® p 11 ( ) « ) » < v, < ' E { c«e... 1 2 { ) 9 ) ?■ > -4 

t $ A ' ■' ? ( T ^ P v p t ) ■? 


I. C C ¥ ) ! $ 
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INDEX 


Accessibility map, 6-9 

Additions to Non-resident Monitor, 3-4 
Automatic Priority Interrupt (API), 7-1 
hardware, 7-4 
implementation, 7-11 
ON/OFF, 4-19 
software, 7-7 


Bad Allocation Table (BAT), 6-18 

Bank/Page mode, 7-1 

Batch mode - DAT slot assignments, 4-20 

Block checksum, 6-7 

Block control pair, 6-6, 6-7 

Block list, 6-14 

Block word count (BWC), 6-6 

BOSS-15, 8-1 

accounting, 8-20 
.DAT slot assignments, 4-20 
line editor (B.PRE), 8-21 

Bootstrap, system, 2-1, 2-7, 4-13 
Buffer allocation, 4-20, 5-13, 6-14 


CAL handler, 2-2, 7-1 
Characters, control, 2-16 
Clock operation, 2-14 
Clock routine, 2-8 
COMBLK, 4-13, 5-1 

Commands to Non-resident Monitor, 3-4 
Control characters, 2-14 
Current set, 6-14 


Data modes 
Dump, 6-4 
Image, 6-4 
IOPS, 6-4 
DDT loading, 4-13 

DECtape file organization, 6—1 

Device assignment table (.DAT), 5-13 

Device table, 5-12 

Disk file structure, 6-11 

Disk handler, 2-6 

Disk resident tables, 5-1, 5-9 

Directoried data recording, 6-5 

Directoried DECtape, 6-1 

Dump mode, 6-4 


Error handler, IOPS, 2-2 
Error processor, 2-2, 2-6 
EXECUTE, 4-13 


File accessibility map, 6-7 
File Bit Map, DECtape, 6-2 
File buffer transfer vector table, 5-13 
File identification and location, 6-7 
File information, see Current set 
File locating, 6-7 


File storage, 3-8 
FIOPS, 6-5 


Handlers, I/O device, 7-1 


Image mode, 6-4 
Input/Output (I/O) 

communication table, 5-12 
initialization, 2-8 
I/O device handlers, 7-1 
writing special, 7-10 
IOPS mode,. 6-4 

error handler, 2-2 


Linking Loader, 4-13 
Link status, 7-1 
Loader buffer allocation, 4-20 
Loader, system, 4-1, 4-13 


Magnetic tape, 6-4 
file directory, 6-7 
handlers, 6-5 
storage retrieval, 6-11 
Mass Storage Busy Table, 5-14 
Master File Directory (MFD), 6-12 
.MED error processor, 2-2 
Memory protect, 7-1 
Monitor, resident, 4-13 


Non-directoried DECtape, 6-1 
Nonresident Monitor, 2-14, 3-1 
additions, 3-4 
commands, 3-4 

Operation of DOS, 1-1 
Overlay Table, 5-9, 5-15 

Patch area. Resident Monitor, 2-16 
PATCH, commands to, 3-8 
PIC interrupt service routine 
implementation, 7-11 
PIP, 6-18 

Pre-allocation of blocks, 6-16 

Priority, software level, 7-1 
Procedure files, BOSS, 8-16 
Program control characters, 2-16 


ofile, 3-8 
Queueing, 7-8 


RC0M table, 5-14 
Reserved word locations, 


x-l 


5-14 





Resident Monitor, 2-1, 4-13 
PATCH area, 2-14 
timing features, 2-8 
Retrieval Information Block (RIB), 
6-14 

Run time file (RTF), 8-1, 8-16 


.3COM registers, 5-1 to 5-6 
used by Loaders, 4-17 to 4-19 
SGNBLK, 4-13, 5-1, 5-8, 5-10 
Skip chain, 5-13 
Software level priority, 7-1 
Spare TCB 0 s, 2-17 
Special I/O device handlers, 7-10 
Startup routines, 2-8 

Storage, 4-26, 6-11, 6-16 
Storage allocation tables (SAT's), 
6-1 

Submaps, 6-17 
SYSBLK, 4-13, 5-1 
System 

bootstrap, 2-7 
initialization, 2-8 
Loader, 4-1, 4-13 


Tables used by Loaders, 4-16 
Task Control Block, 2-17 
TCBTAB, 2-17 

Temp List (TLIST), see Block list 
S TIMER routine, 2-14 
Timing features, 2-8 
TRAN routine, 2-7 


User File Directory Table (.UFDT) 

5- 12 

User file labels, 6-9, 6-10 
User identification code (uic), 

6 - 12 
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HOW TO OBTAIN SOFTWARE INFORMATION 


SOFTWARE NEWSLETTERS, MAILING LIST 


The Software Communications Group, located at corporate headquarters in 
Maynard, publishes newsletters and Software Performance Summaries (SPS) 
for the various Digital products. Newsletters are published monthly, 
and contain announcements of new and revised software, programming 
notes, software problems and solutions, and documentation corrections,. 
Software Performance Summaries are a collection of existing problems 
and solutions for a given software system, and are published periodi¬ 
cally. For information on the distribution of these documents and how 
to get on the software newsletter mailing list, write to: 

Software Communications 

P. O. Box F 

Maynard, Massachusetts 01754 


SOFTWARE PROBLEMS 


Questions or problems relating to Digital's software should be reported 
to a Software Support Specialist. A specialist is located in each 
Digital Sales Office in the United States. In Europe, software problem 
reporting centers are in the following cities. 


Reading, England 
Paris, France 
The Hague, Holland 
Tel Aviv, Israel 


Milan, Italy 
Solna, Sweden 
Geneva, Switzerland 
Munich, West Germany 


Software Problem Report (SPR) forms are available from the specialists 
or from the Software Distribution Centers cited below. 


PROGRAMS AND MANUALS 

Software and manuals should be ordered by title and order number. In 
the United States, send orders to the nearest distribution center. 


Digital Equipment Corporation 

Software Distribution Center 

146 Main Street 

Maynard, Massachusetts 01754 


Digital Equipment Corporation 

Software Distribution Center 
1400 Terra Bella 

Mountain View, California 94043 


Outside of the United States, orders should be directed to the nearest 
Digital Field Sales Office or representative. 


USERS SOCIETY 


DECUS, Digital Equipment Computer Users Society, maintains a user ex¬ 
change center for user-written programs and technical application in¬ 
formation. A catalog of existing programs is available. The society 
publishes a periodical, DECUSCOPE, and holds technical seminars in the 
United States, Canada, Europe, and Australia. For information on the 
society and membership application forms, write to: 


DECUS 

Digital Equipment Corporation 

146 Main Street 

Maynard, Massachusetts 01754 


DECUS 

Digital Equipment, S.A. 
81 Route de 1’Aire 
1211 Geneva 26 
Switzerland 





READER'S COMMENTS 


DOS=15 System Manual 
DEC^IS-ODFFA-B-D 


NOTE: This form is for document comments only. Problems 

with software should be reported on a Software 
Problem Report (SPR) form (see the HOW TO OBTAIN 
SOFTWARE INFORMATION page). 


Did you find errors in this manual? If so, specify by page. 


Did you find this manual understandable, usable, and well-organized? 
Please make suggestions for improvement. 


Is there sufficient documentation on associated system programs 
required for use of the software described in this manual? If not, 
what material is missing and where should it be placed? 


Please indicate the type of user/reader that you most nearly represent. 

□ Assembly language programmer 

f~~] Higher-level language programmer 
f ] Occasional programmer (experienced) 

□ User with little programmina experience 

□ Student programmer 

HI Non-programmer interested in computer concepts and capabilities 

Name ______ Date____ 

Organization __ 

Street-________ 

City.--- State ___Zip Code___ 

or 

Country 

If you do not require a written reply, please check here. I 1 






BUSINESS REPLY MAIL 

NO POSTAGE STAMP NECESSARY IF MAILED IN THE UNITED STATES 


Postage will be paid by: 
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Software Communications 
P. 0. Box F 

Maynard, Massachusetts 01754 
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printed in U.S.A. 






